Hi,
I have some build robots running, whose logs showed this up; so
switched them to use -t for a day or so and caught another example of
the bug. First, here's a successful cvs log: <quote>
-> main loop with CVSROOT=:pserver:[EMAIL PROTECTED]<domain>:/var/cvs/cvsroot
-> Connecting to cvs.<domain>(<IP address>):2401
cvs log: warning: unrecognized response `S -> serve_directory (modules)' from
cvs server
cvs log: warning: unrecognized response `S -> dirswitch (modules,
/var/cvs/cvsroot/Opera/modules)' from cvs server
cvs log: warning: unrecognized response `S -> serve_directory (.)' from cvs
server
cvs log: warning: unrecognized response `S -> dirswitch (.,
/var/cvs/cvsroot/Opera)' from cvs server
cvs log: warning: unrecognized response `S -> do_cvs_command (log)' from cvs
server
cvs log: warning: unrecognized response `S -> server_notify()' from cvs server
S -> server_pathname_check (modules/readme.txt)
S -> Reader_Lock(/var/cvs/cvsroot/Opera/modules)
S -> Simple_Lock_Cleanup()
-> Lock_Cleanup()
</quote> and here's the next iteration of the robot attempting the
same command: </quote>
-> main loop with CVSROOT=:pserver:[EMAIL PROTECTED]<domain>:/var/cvs/cvsroot
-> Connecting to cvs.<domain>(<IP address>):2401
cvs [log aborted]: end of file from server (consult above messages if any)
-> Lock_Cleanup()
</quote>
In between these, it's done a successful cvs up (on entirely different
bits of source tree from the one in which the cvs log happened) which
has reported two locally modified files (the ones in which I'd added
-t flags to get the above output).
My .cvspass has three entries; one for the CVSROOT partially obscured
above, one for similar for documentation.<domain> and one for (null).
My .cvsrc says <quote>
cvs -q
diff -b
update -dP
</quote>
As you can see, the failing cvs log has produced no useful message to
explain why it gets unexpected EOF.
cvs --version reports 1.11.19 on the client (where the robot runs) and
1.12.9 on the server. The client is Fedora Core release 4 (Stentz)
running a 2.6.11 kernel; the server is Debian GNU/Linux 3.1 running a
2.6.13 kernel (according to /etc/issue and /proc/version variously).
If you can suggest other things I can change in command lines to get
more information out, please let me know. The robot is always
running, and has been getting about one of these aborts per day since
the start of this year (hmmm ... which is when that machine last got
re-booted and I re-started the robot by hand), so it's a fairly
convenient way to get log output in a highly reproducible controled
environment,
Eddy.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
