Re: buildbot failure in [...]

["Malte S. Stretz" <ms...@gmx.net>]

On Friday 17 December 2004 11:36 CET buildbot@bugzilla.spamassassin.org 
wrote:
> The Buildbot has detected a new failure of trunk-debian-stable.
>
> Buildbot URL: http://bugzilla.spamassassin.org:8010/
>
> Build Reason: changes
> Build Source Stamp: 112
> Blamelist: quinlan
>
> BUILD FAILED: failed svn

Those messages are getting a bit annoying, is there any way to filter any 
builtbot message which contains "BUILD FAILED: failed svn" on the server?

Cheers,
Malte

-- 
[SGT] Simon G. Tatham: "How to Report Bugs Effectively"
      <http://www.chiark.greenend.org.uk/~sgtatham/bugs.html>
[ESR] Eric S. Raymond: "How To Ask Questions The Smart Way"
      <http://www.catb.org/~esr/faqs/smart-questions.html>

Re: buildbot failure in [...]

[Sidney Markowitz <si...@sidney.com>]

I had a power glitch here which rebooted the server. I think it happened 
in the middle of the svn update causing all three slave jobs to fail, 
and I think that it was a power glitch that caused the reboot. I'm not 
going to bother to bring the buildbot slaves online again before I leave 
on Holiday. The keepalive may have kept them going ok before the power 
failure, but it was too short a timespan to be sure.

  -- sidney

Re: buildbot failure in [...]

[Theo Van Dinter <fe...@kluge.net>]

On Sat, Dec 18, 2004 at 04:31:54PM +0000, Nix wrote:
> don't multiply it by more than, say, ten. If SA goes fifty days without
> a commit something is very wrong. :)

I know nothing about buildbot (haven't had time to look into it), but is there
some way the server can keep track of the commits, and the child can just come
in and query "any work for me?" aka "any work since commit #?"  They can chat
and tests can occur, then when the child is done, it disconnects, waits X,
then connects back and tries again?

It would seem like that would be a bit more efficient than having all clients
constantly connected to the server.

-- 
Randomly Generated Tagline:
echo "Your stdio isn't very std."
              -- Larry Wall in Configure from the perl distribution

Re: buildbot failure in [...]

[Nix <ni...@esperi.org.uk>]

On Fri, 17 Dec 2004, Michael Parker stated:
> I don't think it's so much a dynamic-IP thing as a NAT thing.  Without
> lots of activity (we can go a day or so at a time without a commit)
> the slaves just stop talking to the master and with the connection
> gone behind the NAT the master can't find them.

With most NAT systems worth their salt, this timeout is configurable.

For example, on Linux systems using netfilter (2.4 and 2.6 kernels),
writing a time in seconds to the file
/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established will
fix it for IPv4 TCP streams: the default value is 432000 (five days).
If you knock it up *too* far, you might see scalability problems, so
don't multiply it by more than, say, ten. If SA goes fifty days without
a commit something is very wrong. :)

-- 
`The sword we forged has turned upon us
 Only now, at the end of all things do we see
 The lamp-bearer dies; only the lamp burns on.'

Re: buildbot failure in [...]

[Michael Parker <pa...@pobox.com>]

On Fri, Dec 17, 2004 at 10:14:16AM -0800, Justin Mason wrote:
> 
> (b) however the -parker- and -sidney- ones *are* getting annoying. ;)  I
> suggest we turn off those slaves until we can figure out how to get
> buildbot to work with dynamic-IP slaves...
> 

I don't think it's so much a dynamic-IP thing as a NAT thing.  Without
lots of activity (we can go a day or so at a time without a commit)
the slaves just stop talking to the master and with the connection
gone behind the NAT the master can't find them.

My tuit supply is limited at the moment, but when I get a chance I was
gonna try to hack up a sort of ping command that could be issued via
cron to keep the connection alive.

Michael