Build_farm suggestion and patch to reduce log output

[Vance Lankhaar]

Hi Paul,

On Mon, 2004-08-16 at 16:52, Paul Green wrote:
> I'd like to suggest that the smbd log file, which is presently appended
> to the regular log file at line 267 of build_test.fns, instead be
> renamed and rsync'd separately back to the main web site.  I think this
> would make it a lot easier to open up a couple of windows and have one
> of them show the client side of a failed test, and the other show the
> server side of a failed test.  Right now, if either a lot of tests fail,
> or if a particular test is verbose, it can be a royal pain to search the
> log file.

First, I'm a little hesitant to have a separate log file for each test,
The main reason is that I *think* it would require quite a large number
of changes to web/build.pl in order to handle the log files. (though, if
we were to make those changes, it would make sense to do the same with
the stdout from the tests too, so that we could pair the stdout and
log.smbd together easier)

As for easier to open separate windows for client/server, I'm afraid I
don't see how that'd be much easier. Right now, you can do that fairly
easily (at least, the way I see it ;)). In the first window, find the
stdout stuff, and in the second window, find the log.smbd stuff. 
(remember, you can "close" the tests you're not interested in by
clicking on the name of it.)

I think that it would indeed be very nice to have the log.smbd output
next to the stdout, but I really don't think I have time to do the work
necessary to make it happen. School starts soon and therefore so does
homework... That being said, naturally, I welcome patches :)

(also, it should be fairly easy to add a link between the stdout and the
log.smbd sections. If you're interested in doing that, let me know... I
have a few ideas.)


> In particular, I have discovered that when the "DIR1" test fails, it
> generates about 4M lines of output at level 10.  I made a small patch to
> source/lib/util.c (in the is_in_path function) that *greatly* reduces
> this figure.  See below.  Does anyone besides me think this is an
> acceptable reduction in the trace output?  If so, I'll apply it.

Looks sane to me :)

> Thanks
> PG

Cheers, Vance
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20040818/c1914acc/attachment.bin