[Buildbot-devel] Re: BuildBot test fails on Win32 platform.

[Nick Trout]

> buildbot work, but when there a problems it helps to have a highly-
> motivated
> person at the other end :).

If we get a successful build system working then we'll try and help
maintain the windows sku. I've yet to delve into BB in any real depth,
as I keep saying I'd like to get these tests working before proceeding.

>   usePTY=True, in which case we only expect one stream out of the
command
>   usePTY=False, in which case we expect separate stdout and stderr

Sounds like a plan.

>  in the unix world, the purpose of using the PTY is to get a separate
> process

Okay, I'm not a unix ninja. I know enough to get around, but I'm
certainly not an admin. I'll try and help how I can, but you'll have to
nudge me in the right direction (as you seem to be doing!) if I make any
suggestions. :-)

>  clean up better. The downside is that stdout and stderr are merged
>  (interleaved), since both file descriptors are pointing at the same
pipe.

Ah, okay, that would explain that.

>  Now, in the windows world, I'm not assuming the existence anything
like
>  process groups, so I'd be fine with setting usePTY=False all the time
(in

Just googling quickly it looks like windows server has a notion of
process groups, but don't know anything about them in Windows. I'd guess
they are not available because of the Python docs on Process Parameters
(6.1.1).

>  fact I think the code does this internally). But does windows have
the
>  concept of stdout vs stderr? From your message it sounds like it
does.

Yes it does. But I don't know the caveats involved.

>  I'm studying your slave_win32.patch (SF#1185548) more closely before
>  applying it, because I want to make sure that 1) we're testing that
these
>  streams are interleaved, not just appended, and 2) that it makes
sense to
>  have usePTY=True on windows at all.

Sure. As I explained, I made a few assumptions and tried to fix the
test.

> web_pathname_port:
> 
>  this test involves two separate listening TCP sockets: it's using a
>  "web.distrib" distributed publisher. The first socket is the resource
> that's
>  being published (and is speaking "PB", twisted's RPC protocol). The
> second
>  socket is the actual web server, and is speaking HTTP.

It wasn't documented so I really don't know what it's trying to achieve,
or why it is failing. The windows version just times out and then the
test fails.

Nick