ST> Is that the most recent sumo? Yes, I'm afraid it is. ST> maybe Norbert can do a release of a sumo soon-ish. That'd be great. cheers, mike _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Norbert> I still support Steve's plan to hack something into 21.4 which Norbert> allows us to build the packages. Yeah, I lost track of what happened to that plan. Is it waiting for approval by Vin? Is it waiting for someone to implement it? Norbert> Or do you think it's worth releasing the packages based on the Norbert> beta? Hmm. We don't guarantee that packages that were built on 21.5 can be used with 21.4, do we? cheers, mike _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Vladimir G. Ivanovic writes: Feel free to try it. The problem is that there are extensions to the 21.4 format that are used in 21.5 .elcs that 21.4 can't handle. Since we already know how to fix the build on 21.4, I don't think it's worth doing and don't plan to put in any effort toward that myself. (Ie, I don't even know what those extensions are and feel no need-to-know). In fact we have two fixes. One which involves changes to 21.4 and thus is not backward compatible to existing installations in the sense that anyone with an existing installation < 21.4.22 who wants to build all packages would have to upgrade to 21.4.22. The other involves a monkey-patch which could be added to the package build process and used only on those installations that don't support it (it involves adding a new variable, and thus a boundp test for that variable would be definitive). The former fix is preferred by Mike but Vin isn't doing anything about it, and the latter requires monkey-patching, which has its own set of problems. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Mats Lidell writes: Some people just don't want to rebuild XEmacs for whatever reason. I really don't like the idea of requiring people to upgrade when we've promised that the packages will support 21.4. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Mats Lidell writes: No, GNU Emacs and zappo did that by abusing the heck out of autoloads. We're just trying to maintain compatibility. That's because Mike has been objecting to the monkey-patch solution, Vin hasn't gotten a clear signal that we need a release of 21.4 with the autoload abuse in it, and I haven't had time to push an override through for either the monkey-patch solution or the 21.4 update. Here's the monkey-patch solution again (I think I've posted this before but I'm not sure where). Apply the diff below to XEmacs.rules Index: XEmacs.rules =================================================================== RCS file: /pack/xemacscvs/XEmacs/packages/XEmacs.rules,v retrieving revision 1.62 diff -u -r1.62 XEmacs.rules --- XEmacs.rules 29 Feb 2008 07:17:14 -0000 1.62 +++ XEmacs.rules 18 Dec 2008 01:42:34 -0000 ＠＠ -66,6 +66,9 ＠＠ # PRELOADS = additional command-line arguments needed when compiling .elcs # AUTOLOAD_PATH = subdirectory in source tree where .elcs are located (this # is where auto-autoloads.el, etc. will be placed) +# PACKAGE_FUTURE = -l ../../package-future.el (This file monkey-patches the +# running xemacs with features required by certain packages that are not +# available in older XEmacsen.) # # Doc files (see below): # ---------------------- ＠＠ -496,7 +499,7 ＠＠ $(LOAD_AUTOLOADS) \ -eval "$(AUTOLOAD_PACKAGE_NAME)" \ -eval "$(AUTOLOAD_FILE)" \ - -l autoload -f batch-update-autoloads $^ + -l autoload $(PACKAGE_FUTURE) -f batch-update-autoloads $^ ＠touch $(AUTOLOAD_PATH)/auto-autoloads.el ＠rm -f $(AUTOLOAD_PATH)/auto-autoloads.el~ endif Then add "PACKAGE_FUTURE = -l ../../package-future" to the Makefiles for packages that need it (currently ede and semantic), where package-future.el is ;;; package-future.el --- update XEmacs to deal with modern packages ;; Copyright (C) 2007 Free Software Foundation, Inc. ;; Author: Stephen J. Turnbull <stephen(a)xemacs.org&gt; ;; Maintainer: XEmacs Development Team ;; Keywords: packages ;; This file is part of the XEmacs package distribution. ;; The XEmacs packages are free software; you can redistribute it and/or ;; modify them under the terms of the GNU General Public License as ;; published by the Free Software Foundation; either version 2, or (at ;; your option) any later version. ;; The XEmacs packages are distributed in the hope that they will be ;; useful, but WITHOUT ANY WARRANTY; without even the implied warranty ;; of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the ;; GNU General Public License for more details. ;; You should have received a copy of the GNU General Public License ;; along with the XEmacs packages; see the file COPYING. If not, write ;; to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, ;; Boston, MA 02110-1301, USA. ;;; Commentary: ;; This file contains monkey-patches required to provide functionality ;; missing in older XEmacsen but needed to build some recent packages. ;; To use it, add ;; ;; PACKAGE_FUTURE = -l ../..package-future.el ;; ;; to a package's XEmacs Makefile. ;; To add features to this file, ... well, be a wizard, then do wizardly ;; things. Remember that a True Wizard avoids disturbing the Equilibrium ;; needlessly. Carefully protect the pristine XEmacs from unneeded ;; monkey-patches! Try to use exact tests. ;;; Code: (unless (emacs-version>= 21 5 29) ;; We monkeypatch the make-autoload function so it can handle recent ;; packages like JDE that require extension of the class of functions ;; that must generate autoloads. (terpri) (princ "***** WARNING: monkey-patching `make-autoload'. *****") (terpri) (require 'autoload) ;; Add operator definitions to autoload-operators.el in the xemacs-base ;; package. (ignore-errors (require 'autoload-operators)) (unless (boundp 'autoload-make-autoload-operators) (defvar autoload-make-autoload-operators '(defun define-skeleton defmacro define-derived-mode define-generic-mode easy-mmode-define-minor-mode easy-mmode-define-global-mode define-minor-mode defun* defmacro*) "defun-like operators that use `autoload' to load the library.")) (fmakunbound 'make-autoload) (defun make-autoload (form file) "Turn FORM into an autoload or defvar for source file FILE. Returns nil if FORM is not a special autoload form (i.e. a function definition or macro definition or a defcustom)." (princ (format ".. transforming %s in %s\n" form file)) (let ((car (car-safe form)) expand) (cond ;; For complex cases, try again on the macro-expansion. ((and (memq car '(easy-mmode-define-global-mode easy-mmode-define-minor-mode define-minor-mode)) (setq expand (let ((load-file-name file)) (macroexpand form))) (eq (car expand) 'progn) (memq :autoload-end expand)) (let ((end (memq :autoload-end expand))) ;; Cut-off anything after the :autoload-end marker. (setcdr end nil) (cons 'progn (mapcar (lambda (form) (make-autoload form file)) (cdr expand))))) ;; For special function-like operators, use the `autoload' function. ((memq car autoload-make-autoload-operators) (let* ((macrop (memq car '(defmacro defmacro*))) (name (nth 1 form)) (body (nthcdr (get car 'doc-string-elt) form)) (doc (if (stringp (car body)) (pop body)))) ;; `define-generic-mode' quotes the name, so take care of that (list 'autoload (if (listp name) name (list 'quote name)) file doc (or (and (memq car '(define-skeleton define-derived-mode define-generic-mode easy-mmode-define-global-mode easy-mmode-define-minor-mode define-minor-mode)) t) (eq (car-safe (car body)) 'interactive)) (if macrop (list 'quote 'macro) nil)))) ;; Convert defcustom to a simpler (and less space-consuming) defvar, ;; but add some extra stuff if it uses :require. ((eq car 'defcustom) (let ((varname (car-safe (cdr-safe form))) (init (car-safe (cdr-safe (cdr-safe form)))) (doc (car-safe (cdr-safe (cdr-safe (cdr-safe form))))) (rest (cdr-safe (cdr-safe (cdr-safe (cdr-safe form)))))) (if (not (plist-get rest :require)) `(defvar ,varname ,init ,doc) `(progn (defvar ,varname ,init ,doc) (custom-add-to-group ,(plist-get rest :group) ',varname 'custom-variable) (custom-add-load ',varname ,(plist-get rest :require)))))) ;; Coding systems. #### Would be nice to handle the docstring here too. ((memq car '(make-coding-system make-8-bit-coding-system)) `(autoload-coding-system ,(nth 1 form) '(load ,file))) ;; nil here indicates that this is not a special autoload form. (t nil))))) ;;; end monkey-patches for pre-21.5.29 ;;; monkey-patches to provide autoloads for EIEIO object definitions (add-to-list 'autoload-make-autoload-operators 'defclass) (add-to-list 'autoload-make-autoload-operators 'defmethod) ;;; end monkey-patches for EIEIO ;;; package-future.el ends here _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Mike Kupfer writes: Even if they've got a corporate IT dept breathing down their neck? I know several people who work in environments where it's much easier to get approval to add or upgrade a single Lisp package than to get all of XEmacs upgraded. Whether they use our package format for distribution of those I don't know. It doesn't affect byte-compilation at all. It affects anybody who wants to build auto-autoloads for ede and semantic (and maybe other packages by now), whether in the package system or not.[1] You agree that's something that a "typical user" of ede and semantic would want to do? Footnotes: [1] The problem is that these packages add a bunch of "defsomethings" that need to be treated as defuns in auto-autoload files, which 21.4 doesn't know about. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Mike Kupfer writes: If you've done "cd /path/to/some/package; make" then you have done so, although you may not have been aware of it. ;-) This is the real problem with the "fix 21.4" solution, in any case. It doesn't fix the underlying problem, which is that there is no provision for further extensions of this kind. If there are any (and I bet there will be, I can think of at least one def* I'd like to have, namely "defnamespace"), then we'll have to fix 21.4 again. As package-future.el shows, there's no need to suffer through that. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

MK> I don't see it as suffering, It just occurred to me that I've been assuming we can get timely releases of 21.4. If that's not the case, then I agree that a monkey-patch approach is preferable. mike _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

On Wednesday 17 December 2008, Jerry James wrote: How about a 3rd approach: simply revert (temporarily or move to a branch) or otherwise get out of the way the packages/updates that cause the current failures, and release the rest? And possibly rebuild everything without the offending new/updated packages and let the resulting set cook in experimental for a while before release. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Hi, Mike Kupfer writes: Maybe. If I remember correctly though there was an opening that would allow individual packages to be upgraded to GPLv3. I think Stephen wanted to consult a lawyer on the issue first though before we could go along wih that. Do I remember correctly Stephen? Any news on that? No I'd rather go with the fix and go forward approach. Yours -- %% Mats _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Mike Kupfer writes: He has said that he is. Let me go ahead, test with 21.4 again (it's been a few months), and submit a formal patch. Mike Sperber had an opposing opinion, but since nothing seems to be moving on the 21.4 front at the moment, what do you say, Mike? Note that I don't like monkey-patching either. I think Mike's patch to 21.4 should be applied and released, on Vin's schedule. However, the monkey patch can be done *now* and gradually obsoleted as almost all 21.4 users upgrade to >21.4.21. It might even work for 21.1 users, but I doubt they can build all packages for other reasons. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Michael Sperber writes: What exactly do you want from "not stay forever"? My proposal is a monkey-patch that checks for the necessary function, and installs only if not present. Then, Vin puts your patch into 21.4, and the monkey-patch obsoletes itself. Do you want the monkey-patch to be explicitly removed at some point? If so, I'll put a note in it (and maybe an issue in the tracker) to remove it by some deadline. If that's what you want, suggestions for a deadline? _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

On Tue, Dec 23, 2008 at 8:13 AM, Michael Sperber <sperber(a)deinprogramm.de&gt; wrote: Earth to Vin. Come in Vin. Over. Zzz.z.z.ork. I'm here..... I've been trying to remember what exactly the status of all this was wrt to 21.4 and finally I remembered. I filed away Michael's shortly before my son arrived and hadn't gotten back to it. Michael's patch didn't apply cleanly to the 21.4 base. I'll investigate today and send back an email. Assuming I encounter no major difficulties, I don't see why I can't turn a 21.4 release out by 2009-01-01. - Vin _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta