After installing this version of VM (by hand), I can't use VM at all. Invoking VM, I get: Signaling: (file-error "Cannot open load file" "vm") load-internal("vm" nil t nil nil nil) load("vm" nil t nil) require(vm) vm-session-initialization() #<compiled-function (&optional folder read-only) "...(7)" [vm-session-initialization done (byte-code "À !?Â????À !«f ªÝ ®?É\n \" Í !«?ÎÏ \"ªÄÐ !®¾ «?É !®'ÒÂÓ×Ø \"^Ù ! ®'\n?＠s¬?B)×Ü \"^,)?q^ÝB«Åà!àá!=¬»à!àâ!=¬±à!àã!=¬§à!àä!=¬Âå &'èŽéed#^êÓÂ\"^ëed#^+ì ^í ^å ¬fî/0ñ=?2­<å ?­?óô 2\"?®Ž5®Sö÷!®... ­''7 «-øp!^ùî!^úî!^û ^å ¬"ü ýÂ?Â#^ «(tm)¬*þ ^ÿ ^＠ ^A ^B ^ «...C ^«-D«"E F «...G ªfH \"^««I®...J®pKL K?DCD®fM N D$^O«...P ^)«...Q R ^S ^T «sU«-ׁV !^W ^ׁX !^Y ^Z«<[ «...\\ ^«Ð] «S ¬?^ ÒÂ\"^I«'_«`«?O«...P ^a«-L Â?DCD®fM N D$^ªSb I®...J®p!^)c«...d ^e f !^«"× !^« «Sׁg h !!^«f «?i j Ò\"^k«½l¬¹7¬µ×m 2®"n \"^o Ò!«oeýÒ!«-Q R «?d ^ª...S ^× !^t­"p?­q ^r ?­f× !.?" ... 7)] 2 "Read mail under Emacs.\nOptional first arg FOLDER specifies the folder to visit. It defaults\nto the value of vm-primary-inbox. The folder buffer is put into VM\nmode, a major mode for reading mail.\n\nPrefix arg or optional second arg READ-ONLY non-nil indicates\nthat the folder should be considered read only. No attribute\nchanges, message additions or deletions will be allowed in the\nvisited folder.\n\nVisiting the primary inbox causes any contents of the system mailbox to\nbe moved and appended to the resulting buffer.\n\nAll the messages can be read by repeatedly pressing SPC. Use `n'ext and\n`p'revious to move about in the folder. Messages are marked for\ndeletion with `d', and saved to another folder with `s'. Quitting VM\nwith `q' expunges deleted messages and saves the buffered folder to\ndisk.\n\nSee the documentation for vm-mode for more information." (list nil current-prefix-arg)>(nil nil) call-interactively(vm) command-execute(vm t) execute-extended-command(nil) call-interactively(execute-extended-command) -lipp -----Original Message----- From: SL Baur [mailto:steve＠xemacs.org] Sent: Saturday, September 19, 1998 11:14 PM To: xemacs-beta(a)xemacs.org Subject: Release notes -- package update 1998/09/19 [Important question for the folks working on package installers at the bottom.] I've updated all the packages in ftp://ftp.xemacs.org/pub/xemacs/packages/ A massive SUMO tarball of the staging area after I was done building (which should now be equivalent to the results obtained installing everything by hand) is at: ftp://ftp.xemacs.org/pub/xemacs/packages/xemacs-SUMO-1998-09-19.tar.gz It's probably not runnable without deleting some packages by hand first. The index file is: ftp://ftp.xemacs.org/pub/xemacs/packages/package-get-base.el-1998-09-19 The only code updates were vm-1.11: Synch with VM 6.62 pgnus-1.01: Synch with Pterodactyl Gnus 0.31 Everything else is repackaging. A handful of packages had some files rearranged. mule-base no longer creates two subdirectories in etc/. rmail, xemacs-base, and viper no longer create subdirectories for their data files. A handful of packages had their READMEs and other documentation restored. The user visible changes are: No more _pkg.el files. I haven't decided whether this is a good idea or not. *Not* including them means that the auto-autoloads.el can't be properly updated and this is probably a bad thing. Every package includes a manifest file of the form pkginfo/MANIFEST.$(PACKAGE). This should make a safe package delete function a slam dunk. TexInfo sources are now included in subdirectories of a new package top-level directory called man. There probably ought to be an option at installation time as to whether they should be installed or not, since they're not actually needed at run-time. Build level changes: The way files are copied to the installation or staging area has been fixed. There is no much more restricted use of wildcards, and it should now be possible to safely `make install' into a tree you are running from. In particular, the copy *.el* is now history. Packages that are custom-ized are now required to have GENERATED += custom-load.elc after they include XEmacs.rules. For packages with data files that go into etc/, there are two symbols which must be defined. The symbol `DATA_FILES' should be a list of files to be copied relative to the package build directory (eg. comm/footnote, etc.) in exactly the same fashion ELCS works now. examples: DATA_FILES = relative/path/to/each/data/file DATA_FILES = $(wildcard images/*.png) The symbol DATA_DEST indicates where in etc/ the files are to be copied to. Typically it should be set to $(PACKAGE), but if files need to be placed directly in etc/, it can be ".". The installation directory is built up as `etc/$(DATA_DEST)/'. The semantics of INFO_FILES has been changed so that it works the same way `ELCS' and `DATA_FILES' does. Every file listed gets installed into info/. For packages with texinfo documentation, there are two new symbols. `TEXI_FILES', which should be set the same way `ELCS', `DATA_FILES', and `INFO_FILES' are set and `MANUAL'. Every file listed in `TEXI_FILES' will be installed into the directory man/$(PACKAGE)/. The variable `MANUAL' is left as a hook if someone wants to hack together something to build hardcopy. example assuming two manuals, `foo' and `bar': TEXI_FILES = texi/foo.texi texi/bar.texi texi/gpl.texinfo MANUAL = foo bar It is important for packages that do not have data files, or texinfo files to not set these variables (I found one package which did, but I fixed it). I'm going to try to create a template package Makefile tonight, and write some formal documentation on this. With only two primary[1] exceptions (Gnus[2] and psgml[3]), every package now has a generic build target. *Question for the people who have been coding installation clients:* The `standards-version' has been held at 1.0, but there is enough of an interface change, particularly the new existence of a MANIFEST file , to warrant changing the version number. Will this help out coding? Basically, you would know that any package with standards-version 1.0 doesn't have delete information, and anything higher means it does. Footnotes: [1] As opposed to the three packages which contain no installable lisp and need some handholding because there is no non-source install target. [2] Multiple etc/ directories aren't handled automatically. [3] 2nd level subdirectories in etc/ are now not handled automatically.