Hi, an interesting problem has been plaguing the pkgsrc editors/xemacs build for a while. Some time ago, I updated editors/xemacs-packages to deploy the pre-release packages from beta/experimental/packages. Since that update, rebuilding xemacs with editors/xemacs{,-packages} installed will fail with [...] Loading loadhist.el... Loading loaddefs.el... Loading site-load.el... Bootstrapping from temacs... Compiling /usr/pkg/lib/xemacs/xemacs-packages/lisp/leim/hebrew.el... /usr/pkg/lib/xemacs/xemacs-packages/lisp/leim/hebrew.el: Opening output file: directory not writable or nonexistent, /usr/pkg/lib/xemacs/xemacs-packages/lisp/leim/hebrew.elc Done + exit 1 *** [update-elc.stamp] Error code 1 make[1]: stopped in /var/obj/pkgsrc/editors/xemacs/work/xemacs-21.4.24/src 1 error [...] That is, there is no compiled equivalent for hebrew.el % > ls -l /usr/pkg/lib/xemacs/xemacs-packages/lisp/leim/hebrew.* -rw-r--r-- 1 root wheel 24602 Dec 14 2015 /usr/pkg/lib/xemacs/xemacs-packages/lisp/leim/hebrew.el % and the xemacs build feels called to compile the installed el file, which as an unprivileged build it cannot. Now, is it a problem when packages ship some of their source files uncompiled? And if it isn't, why should the xemacs build system attempt to recompile arbitrary installed el files? And where exactly in the build does that happen? Would the strategy be to make sure that all packages install compiled sources, or to slap the wrist of xemacsens build system when it tries to reach out beyond the build directory? Cheerio, hauke -- The ASCII Ribbon Campaign Hauke Fath () No HTML/RTF in email Institut für Nachrichtentechnik /\ No Word docs in email TU Darmstadt Respect for open standards Ruf +49-6151-16-21344