Bug#336935: debian-el: [gnus-BTS.el] Invalid function macro t rying to view an article
Luca Capello [EMAIL PROTECTED] wrote: Hello Peter! Hi Luca, On Thu 03 Nov 2005 03:11 +0100, Peter S Galbraith wrote: Luca Capello [EMAIL PROTECTED] wrote: = Debugger entered--Lisp error: (invalid-function (macro . #[(group) ÃÃDCÃBBâ¡ [group let gname ((if (string-match ^[^:]+: gname) (substring gname (match-end 0)) gname))] 3 (/usr/share/emacs-snapshot/site-lisp/gnus/gnus-util.elc . 16633)])) gnus-group-real-name(nnimap+pcaserver:INBOX) This is a macro defined in gnus-util.el. I knew it, but I think it's gnus-BTS.el specific (read below). I didn't mean to imply otherwise, sorry. It was almost a note to myself... Strangely, it seems that the function (gnus-group-real-name gnus-newsgroup-name) seems working if evaluated with M-:, so I don't know the cause of the problem. BTW, emacs-snapshot with gnus package. Perhaps something got byte-compiled with one version of gnus and used with another. Do you have the gnus package installed? I've the gnus package installed and I haven't byte-compiled anything (except for the automatic Debian installation), but I can try, if needed. What is happenning is that gnus-BTS gets byte-compiled against the stock gnus and used with the packaged gnus. For one thing, I'm not sure that the packaged gnus should be used by emacs-snapshot since it would have a bleeding-edge gnus. It's very likely that this problem goes away if you uninstall the gnus package. If so, I'll fix the problem by skipping byte-compilation for gnus-BTS.el. -- Peter
Bug#336935: debian-el: [gnus-BTS.el] Invalid function macro t rying to view an article
Peter S Galbraith [EMAIL PROTECTED] wrote: What is happenning is that gnus-BTS gets byte-compiled against the stock gnus and used with the packaged gnus. For one thing, I'm not sure that the packaged gnus should be used by emacs-snapshot since it would have a bleeding-edge gnus. It's very likely that this problem goes away if you uninstall the gnus package. If so, I'll fix the problem by skipping byte-compilation for gnus-BTS.el. Now I'm very confused because I already skip byte-compilation of gnus-BTS! What is the output of `M-x locate-library gnus-BTS' ? It should be: Library is file /usr/share/emacs/site-lisp/debian-el/gnus-BTS.el -- Peter -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336935: debian-el: [gnus-BTS.el] Invalid function macro t rying to view an article
Hello Peter! On Thu 03 Nov 2005 15:53 +0100, Peter S Galbraith wrote: Luca Capello [EMAIL PROTECTED] wrote: I knew it, but I think it's gnus-BTS.el specific (read below). I didn't mean to imply otherwise, sorry. It was almost a note to myself... No problem, I checked gnus-utils.el before, to be sure of the correct package to submit the bug ;-) I've the gnus package installed and I haven't byte-compiled anything (except for the automatic Debian installation), but I can try, if needed. What is happenning is that gnus-BTS gets byte-compiled against the stock gnus and used with the packaged gnus. For one thing, I'm not sure that the packaged gnus should be used by emacs-snapshot since it would have a bleeding-edge gnus. Well, AFAIK this is not the case, read the bug #322189 [1] for other info (I thought the same before). It's very likely that this problem goes away if you uninstall the gnus package. If so, I'll fix the problem by skipping byte-compilation for gnus-BTS.el. Eheheh... Downgrading it considering not to be safe, as from /usr/share/doc/gnus/GNUS-NEWS.gz: = ** Upgrading from previous (stable) version if you have used No Gnus. If you have tried No Gnus (the unstable Gnus branch leading to this release) but went back to a stable version, be careful when upgrading to this version. In particular, you will probably want to remove the `~/News/marks' directory (perhaps selectively), so that flags are read from your `~/.newsrc.eld' instead of from the stale marks file, where this release will store flags for nntp. See a later entry for more information about nntp marks. Note that downgrading isn't safe in general. = Thx, bye, Gismo / Luca [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=322189 pgpOWC1lRMvg6.pgp Description: PGP signature
Bug#336935: debian-el: [gnus-BTS.el] Invalid function macro t rying to view an article
Luca Capello [EMAIL PROTECTED] wrote: Hello Peter! On Thu 03 Nov 2005 16:59 +0100, Peter S Galbraith wrote: Peter S Galbraith [EMAIL PROTECTED] wrote: Now I'm very confused because I already skip byte-compilation of gnus-BTS! It doesn't seem the case (at least for emacs-snapshot, read below). Ok... that's the bug! What is the output of `M-x locate-library gnus-BTS' ? It should be: Library is file /usr/share/emacs/site-lisp/debian-el/gnus-BTS.el /usr/share/emacs-snapshot/site-lisp/debian-el/gnus-BTS.elc Right... gismo:/home/luca# ls /usr/share/emacs-snapshot/site-lisp/debian-el/ apt-sources.el apt-utils.el debian-bug.el debian-el.el apt-sources.elc apt-utils.elc debian-bug.elc debian-el.elc debian-el-loaddefs.el deb-view.el gnus-BTS.el preseed.el debian-el-loaddefs.elc deb-view.elc gnus-BTS.elc preseed.elc gismo:/home/luca# ls /usr/share/emacs21/site-lisp/debian-el/ apt-sources.el apt-utils.el debian-bug.el debian-el.el apt-sources.elc apt-utils.elc debian-bug.elc debian-el.elc debian-el-loaddefs.el deb-view.el preseed.el debian-el-loaddefs.elc deb-view.elc preseed.elc As you can see, there's a problem: - on emacs21, gnus-BTS.el is not byte-compiled, neither symlinked, in fact M-x locate-library gives No library gnus-BTS in search path; manually creating the symlink gives Library is file /usr/share/emacs21/site-lisp/debian-el/gnus-BTS.el (which is still different from your line, note the emacs21 folder) - on emacs-snapshot, we've both (byte-compiled and symlinked) Good catch. The cause is in /usr/lib/emacsen-common/packages/install/debian-el: = # Don't byte-compile gnus-BTS.el since it uses gnus macros and will cut EXCLUDED_emacs20=gnus-BTS.el EXCLUDED_emacs21=gnus-BTS.el EXCLUDED_xemacs21=gnus-BTS.el = We're missing EXCLUDED_emacs-snapshot=gnus-BTS.el. Sort of... But in this case, gnus-BTS.el will be not available in the path as it's not symlinked. The problem is that I used the EXCLUDED_emacs21 scheme to skip byte-compilation, relying on the fact that the source elisp directory was in the load-path. I recently removed it from the load-path and substituted by the symlinks. But the `EXCLUDED_emacs21' is used for files that are actually imcompatble with a flavour of Emacs. I'll add something else to skip byte-compilation as well and will use it for gnus-BTS.el Thanks for all your help tracking this down! Peter -- Peter S. Galbraith, Debian Developer [EMAIL PROTECTED] http://people.debian.org/~psg GPG key 1024/D2A913A1 - 97CE 866F F579 96EE 6E68 8170 35FF 799E -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
