I'm making progress toward resolving the cleanup problems I have moving from 21.4 to the 21.5 beta. To avoid having to dig through several e-mails with different subject headers and to deal with one thing at a time, I'm starting a new thread. Thanks to the several who gave suggestions regarding getting my packages updated. Someone suggested doing this: (setq efs-ftp-program-args (append efs-ftp-program-args '("-p"))) I've never really understood what passive mode is in FTP. I went out and read an explanation and still don't. Doesn't matter. I seem to recall from previous experience that it doesn't hurt to have it running. Nonetheless, I eval'ed that and stuck it in my init.el in case I need it again, but commented out. More importantly, I think, is the clue that ftp.xemacs.org is broken. As per Stephen's suggestion, I selected ca.xemacs.org, which I guess is the "nearest" mirror -- probably closer than wherever ftp.xemacs.org is (I'm in central Ohio) -- and that enabled me to get an index, which I put in ~/.xemacs. The first time I tried to update packages, it gave me an error that it couldn't write the directory. This makes sense, given that the packages are now in /usr/local space and I installed them using sudo. To get around this, I had to go to a command line and simply did chown -R lnewton: on /usr/local. (There's nothing else there but xemacs stuff.) Although it apparently works right that way, it strikes me as philosophically wrong and broken to go into /usr-land and start changing ownerships and permissions. Isn't there or shouldn't there be a way for the elisp to detect that when a directory tree exists but is unwritable it almost certainly means that it needs to be updated by root, and so should prompt for a password? And while I'm at it, I had to answer some questions about where to put the package index, which is now in my .xemacs directory. I didn't look closely enough at what all it was telling me, but in retrospect I suspect it's the same problem, that it wanted to put the index with the packages but couldn't -- but intelligently allowed me to put it in .xemacs. I should remove it out of there and do the process again to see where it puts the thing. (I hate having stuff in my face in a directory that I don't use.) As far as I can tell, based on the dates that now exist in /usr/local/share/xemacs/xemacs-packages/lisp, everything worked. And it looks like only about a dozen packages have been updated since the sumo was last created. (July 27, 2010) Apparently it's not something I have to worry about very often. Off to slay the next dragon. -- Lynn David Newton Columbus, Ohio neologisticsediting.com lynndavidnewton.com _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta