Re: What's up with the CVS sever?

Thanks, Martin. Switching to pserver in the mule directory has helped somewhat (at least, with downloading) However, this is very inconvenient. Is it a memory problem with the server? Would moving the main repository to sourceforge help? I know this means loosing some degree of control and convenience, but form my experience they are reasonably good at running it, and are getting better. The real problems came when I then ran "make all" in the xemacs-packages directory and got lots of errors. Some of them seem, indeed, to be errors. For instance, make[3]: Entering directory `/home/users/kifer/xemacs-packages/comm/gnus/tm'Makefile:51: ../../XEmacs.rules: No such file or directory The file XEmacs.rules is sitting 3 levels above this, not two. There are many such incorrect include statements in the subdirectories of comm. I don't know whether this is the cause or not, but later I got a lot of beeps with errors like xemacs exiting.Cannot open load file: texinfmt make[2]: *** [vm.info] Error 255 make[2]: Leaving directory `/home/users/kifer/xemacs-packages/comm/vm' xemacs exiting.Cannot open load file: advice make[2]: *** [lisp/base64.elc] Error 255 make[2]: Leaving directory `/home/users/kifer/xemacs-packages/comm/w3' xemacs exiting.Cannot open load file: /home/users/kifer/xemacs-packages/comm/gnus/gnus/lisp/auto-autoloads make[2]: *** [expect.elc] Error 255 Generating autoloads for mule-base/char-table.el... Unbalanced parentheses xemacs exiting. make[2]: *** [auto-autoloads.el] Error 255 Generating autoloads for lisp/lookup-entry.el... Unbalanced parentheses xemacs exiting. make[2]: *** [lisp/auto-autoloads.el] Error 255 Worst of all, when I start xemacs after that it fails to recognize the packages in xemacs-packages, even though I have a symbolic link from xemacs/xemacs-packages to the xemacs-packages directory, which is a CVS copy of that module. --michael