Michael> U mule/skk/etc/ReadMe.English Michael> cvs [server aborted]: can not reallocate 4194304 bytes cgw> I don't know what the problem is, but it's been this way for cgw> at least a month. I get the same error when doing a CVS cgw> update. Since I don't use Mule my workaround is just to cgw> remove the skk subdir and not CVS update the Mule stuff... It's trying to update the JISYO.L which is a huge dictionary data file. I don't understand why CVS has a problem. However, when I removed JISYO.L and cvs update'd, everything was OK. Mea maxima culpa. I forgot to mention this, the file only gets updated once a year or so and since I got the workaround right the first time, it hasn't bothered me, I assumed it was temporary .... -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."

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

* "MB" == Martin Buchholz <martin(a)xemacs.org&gt; writes: Michael> Thanks, Martin. Switching to pserver in the mule directory has helped Michael> somewhat (at least, with downloading) However, this is very inconvenient. Why is that? I use pserver for read-only CVS and ext for write CVS stuff with no problems at all. Michael> The real problems came when I then ran "make all" in the Michael> xemacs-packages directory and got lots of errors. Some of Michael> them seem, indeed, to be errors. For instance, MB> Paging Steve Youngs... Yo! I missed the previous post (and it hasn't shown up on www.xemacs.org/list-archives yet). Could you please send me the errors you are getting. Michael> Worst of all, when I start xemacs after that it fails to recognize the Michael> packages in xemacs-packages, even though I have a symbolic link Michael> from xemacs/xemacs-packages to the xemacs-packages directory, which is a Michael> CVS copy of that module. I think for what you are trying to do you should be linking to the STAGING directory. -- |---<Regards, Steve Youngs>-----------[GnuPG KeyID: 59E4C4B2]---| | XEmacs - It's not just an editor... | | It's a way of life. | |----------------------------------<mailto:youngs＠xemacs.org>---|

Michael> Steve Youngs writes: Michael> Switching to pserver in the mule directory has helped Michael> somewhat (at least, with downloading) However, this is very Michael> inconvenient. Michael> Perhaps I don't know how to do it properly, but I have to edit CVS/Root by Michael> hand to replace :ext:michaelk＠ to :pserver:xemacs＠ Michael> Besides, I think cvs update only looks at CVS/Root in the top directory Michael> where it is invoked. (Didn't check now, but I think I ran into it before.) Michael> So, if this is true, it means that updating the entire package tree might Michael> be more complicated than usual. Although the following is a bug workaround, it's also a good idea - like not running as `root' by default. Do your cvs checkouts using :pserver: . If you've done a checkout using :ext:, you can change all your CVS/Root files using a script (but just once). Some versions of CVS update the CVS/Root files when you run cvs commands with a different -d flag `$CVS_IGNORE_REMOTE_ROOT' For CVS 1.10 and older, setting this variable prevents CVS from overwriting the `CVS/Root' file when the `-d' global option is specified. Later versions of CVS do not rewrite `CVS/Root', so `CVS_IGNORE_REMOTE_ROOT' has no effect. I use the following `cvs-rw' script to run non-read-only CVS commands. Identical to the `cvs' command otherwise. Customize two lines below for your own use. : #-*- Perl -*- eval 'exec perl -w -S $0 ${1+"$＠"}' # Portability kludge if 0; # Author: Martin Buchholz use strict; (my $myName = $0) =~ s＠.*/＠＠; my $usage=" Usage: $myName cvs-arg ... Run cvs in r/w mode. The idea is to do most CVS operations, especially checkout, in read-only, or anonymous :pserver: mode, and only switch to ssh/:ext: mode when performing write operations\n"; die $usage if !＠ARGV || $ARGV[0] eq '-h'; die "Not a CVS repository\n" unless -r "CVS/Root"; open (ROOT, "< CVS/Root") or die "CVS/Root: $!"; chomp (my $root = <ROOT>); # Make $root writable by switching from :pserver: to :ext: # Modify the following two lines for your own CVS commits: $root =~ s/:pserver:anonymous＠(?=.*\bsourceforge\.net:)/:ext:mrb＠/; $root =~ s/:pserver:xemacs＠(?=.*\bcvs\.xemacs\.org:)/:ext:martinb＠/; $ENV{CVS_RSH} = 'ssh'; $ENV{CVS_IGNORE_REMOTE_ROOT} = 'yes'; exec 'cvs', '-w', '-z3', '-d', $root, ＠ARGV or die "Can't run cvs: $!\n";

* "MK" == Michael Kifer <kifer(a)cs.sunysb.edu&gt; writes: Michael> Worst of all, when I start xemacs after that it fails to Michael> recognize the Michael> packages in xemacs-packages, even though I have a symbolic link Michael> from xemacs/xemacs-packages to the xemacs-packages directory, Michael> which is a CVS copy of that module. MK> What's that? Haven't seen any such dir or its mention. You set $STAGING in Local.rules (cp Local.rules.template). MK> Isn't it true that all these packages should be in xemacs-packages? MK> So the link from xemacs/xemacs-packages to the packages dir should do the MK> trick (provided that the packages are built correctly, which I am yet to MK> achieve)? Well it would do the trick if the directory structure in the CVS package tree was the same as what XEmacs expects to find, but it isn't. Which is why it would be extremely difficult to run the packages in place from the CVS tree.[1] This is what you are trying to do isn't it? MK> The real problems came when I then ran "make all" in the xemacs-packages MK> directory and got lots of errors. Some of them seem, indeed, to be errors. For MK> instance, After you create a Local.rules from Local.rules.template and edit it to suit your needs, a better target to run would be "make install". MK> make[3]: Entering directory MK> `/home/users/kifer/xemacs-packages/comm/gnus/tm'Makefile:51: MK> ../../XEmacs.rules: No such file or directory Um, './comm/gnus/tm' isn't in my tree (updated 10 minutes ago). MK> The file XEmacs.rules is sitting 3 levels above this, not two. MK> There are many such incorrect include statements in the subdirectories of comm. Where are they exactly? I don't see these errors when I build the packages. MK> xemacs exiting.Cannot open load file: texinfmt MK> make[2]: *** [vm.info] Error 255 MK> make[2]: Leaving directory `/home/users/kifer/xemacs-packages/comm/vm' MK> xemacs exiting.Cannot open load file: advice MK> make[2]: *** [lisp/base64.elc] Error 255 MK> make[2]: Leaving directory `/home/users/kifer/xemacs-packages/comm/w3' MK> xemacs exiting.Cannot open load file: /home/users/kifer/xemacs-packages/comm/gnus/gnus/lisp/auto-autoloads MK> make[2]: *** [expect.elc] Error 255 MK> Generating autoloads for mule-base/char-table.el... MK> Unbalanced parentheses MK> xemacs exiting. MK> make[2]: *** [auto-autoloads.el] Error 255 MK> Generating autoloads for lisp/lookup-entry.el... MK> Unbalanced parentheses MK> xemacs exiting. MK> make[2]: *** [lisp/auto-autoloads.el] Error 255 Hmm, not good. And what's worse is that I don't see any of these errors when I build the packages. Perhaps you got some file corruption when you checked out the xemacs-packages module (it happened to me once). Check one of those files that gave you the 'unbalanced parentheses' error for strange things. If that's the case you'll need to delete your tree and check out the module again. Footnotes: [1] I didn't say "impossible" simply because I have never tried to do this. -- |---<Regards, Steve Youngs>-----------[GnuPG KeyID: 59E4C4B2]---| | XEmacs - It's not just an editor... | | It's a way of life. | |----------------------------------<mailto:youngs＠xemacs.org>---|