This package is unusable in Debian 11 bullseye in its current state. In my Emacs 1:27.1+1-3.1 session, i run M-x esup and I get: error in process sentinel: Wrong type argument: (or eieio-object class), nil, obj *Messages* has this: Loading /usr/share/emacs/site-lisp/elpa/esup-0.7.1/esup-autoloads.el (source)...done Starting esup... esup process started on port 37851 at 1 error in process sentinel: slot-value: Wrong type argument: (or eieio-object class), nil, obj error in process sentinel: Wrong type argument: (or eieio-object class), nil, obj This is the upstream bug: https://github.com/jschaf/esup/issues/85 It looks like it is a packaging issue, since, according to the above bug report, recompiling the .el files fixes the problem (haven't tested).
Hi Antoine, Вт 27 апр 2021 @ 13:53 Antoine Beaupre <anarcat@debian.org>: Is it a fresh install of elpa-esup? I have elpa-esup installed for a long time and I cannot reproduce the bug on my machine. Running esup starts another GNU Emacs session and gives me a proper report on startup like the following excerpt: ``` Total User Startup Time: 0.357sec Total Number of GC Pauses: 3 Total GC Time: 0.065sec package.elc:16 0.134sec 37% (byte-code "\301\302!\210\301\303!\210 [...] ``` I wonder how recompiling could fix the problem you face, since installing/reinstalling the package or GNU Emacs itself should trigger recompilation of it along with all other installed Emacs packages. The package does not contain any pre-compiled files: ``` $ apt-file show elpa-esup elpa-esup: /usr/lib/emacsen-common/packages/compat/elpa-esup elpa-esup: /usr/lib/emacsen-common/packages/install/elpa-esup elpa-esup: /usr/lib/emacsen-common/packages/remove/elpa-esup elpa-esup: /usr/share/doc/elpa-esup/README.md elpa-esup: /usr/share/doc/elpa-esup/changelog.Debian.gz elpa-esup: /usr/share/doc/elpa-esup/copyright elpa-esup: /usr/share/emacs/site-lisp/elpa-src/esup-0.7.1/esup-autoloads.el elpa-esup: /usr/share/emacs/site-lisp/elpa-src/esup-0.7.1/esup-child.el elpa-esup: /usr/share/emacs/site-lisp/elpa-src/esup-0.7.1/esup-pkg.el elpa-esup: /usr/share/emacs/site-lisp/elpa-src/esup-0.7.1/esup.el ``` So, may it be a bug in dh-elpa or GNU Emacs itself? Cheers! Lev
By the way here is the relevant output from *Message* on my machine: ``` Starting esup... esup process started on port 45217 at 1 esup finished ``` Cheers! Lev
Control: severity -1 normal Yes, installed from the Debian package in Bullseye. Oh interesting! Maybe that's why it works, since the bytecode is older? Yeah, as I said I haven't tried to recompile myself, that's just what the upstream bug report says. If anything, maybe it's the opposite and if *you* recompile you'll trigger the bug? No idea. [...] Maybe! This is way beyond my elisp-fu unfortunately. One key information I have just discovered is that I can't reproduce with `emacs -q`. So this is probably an interaction with my .emacs.d configuration and the package, unfortunately. Downgrading severity. a.
Ср 28 апр 2021 @ 08:50 Antoine Beaupré <anarcat@debian.org>: Well, each update of GNU Emacs and at least sometimes updates of dh-elpa trigger recompilation of all installed packages. On my machine file /usr/share/emacs/site-lisp/elpa/esup-0.7.1/esup.elc starts with ``` ;ELC^W^@^@^@ ;;; Compiled ;;; in Emacs version 27.1 ;;; with all optimizations. ``` That is, it was recompiled at least with installation of GNU Emacs 27.1, which was first uploaded to unstable on 2020-10-24, but I still remember that there were more recompilation of all installed packages recently (probably, even on 2021-04-07 when Emacs 1:27.1+1-3.1 entered testing). I've tried to reinstall elpa-esup, which caused recompilation and still I cannot reproduce your bug both with my config and with emacs -q. It makes it a bit trickier. There another package, elpa-bug-hunter [elpa-bug-hunter], which automatically debug and bisect your init.el or .emacs file. It may be worth t try it with your config. [elpa-bug-hunter] https://tracker.debian.org/pkg/elisp-bug-hunter Cheers! Lev
Mine says the same. [...] Thanks, I'll try that next.
Actually, do you know how I would use bug-hunter and esup together? It seems they *both* start a separate emacs process to debug the startup, and thus would be in conflict with each other... a.
Ср 28 апр 2021 @ 11:44 Antoine Beaupré <anarcat@debian.org>: Guess, you may start Emacs as usual, then edit your configuration to run esup (that is, run it as a last line of your config), and then run bug-hunter. Probably, it will work. Or not. At least, it's worth a try. Cheers! Lev
That didn't work, but I manually bisected my .emacs.d/init.el file and
came up with this minimal reproducer:
(when (require 'package nil t)
(setq-default
load-prefer-newer t
package-enable-at-startup nil)
(package-initialize)
(setq package-archives '(("gnu" . "https://elpa.gnu.org/packages/")
("melpa" . "https://melpa.org/packages/")))
;; in elpa-use-package debian package since stretch
(unless (package-installed-p 'use-package)
(package-refresh-contents)
(package-install 'use-package)))
(eval-when-compile
(require 'use-package)
(setq-default
use-package-always-defer nil
use-package-always-ensure t))
(use-package lsp-mode
:commands (lsp lsp-deferred)
:demand t
;;:init
;;(setq lsp-keymap-prefix "C-c l")
;; TODO: https://emacs-lsp.github.io/lsp-mode/page/performance/
;; also note re "native compilation": <+varemara> it's the
;; difference between lsp-mode being usable or not, for me
:config
(setq lsp-auto-configure t))
It could probably be trimmed down more, and i suspect the 'lsp-mode' bit
is a red-herring: any package would probably trigger it.
A.
Ср 28 апр 2021 @ 14:30 Antoine Beaupré <anarcat@debian.org>: I installed elpa-lsp-mode and tried the config you provided and I can confirm the bug. In *Messages* I can see the following: esup process started on port 44801 at 1 error in process sentinel: slot-value: Wrong type argument: (or eieio-object class), nil, obj error in process sentinel: Wrong type argument: (or eieio-object class), nil, obj But when I tried with other packages (both one by one and together) I cannot reproduce the bug. That is, I commented out lsp-mode part of your config and tried, then tried with several other packages (namely, ansi-color, eyebrowse, anzu, beacon, and undo-tree). I cannot reproduce the bug with any of the mentioned packages neither when I use just one of them instead of lsp-mode, nor any set of these packages instead of lsp-mode. And I tried to remove my custom.el and started with sane configuration of GNU Emacs. Cheers! Lev
Hi Antoine and Lev!
Antoine Beaupré <anarcat@debian.org> writes:
I wonder if this "(package-initialize)" line, while using Emacs >= 27 is
exposing a bug in lsp-mode? Since Emacs 27 now automatically runs
package-initialize in between the new early-init.el and the classic
.emacs.el/init.el/etc, maybe lsp-mode has an autoload cookie that gets
evaluated twice, leading to the broken state of the lsp sentinel?
Alternatively, maybe lsp-mode now assumes we live in a post-Emacs 27
world where all users have already dropped package-initialize from their
configs?
These Emacs >= 27 changes also affect the point in emacs init where
package-enable-at-startup can be set:
If non-nil, packages are made available before reading the init file
(but after reading the early init file). This means that if you
wish to set this variable, you must do so in the early init file.
I think this bug is still valid and actionable even if removing
package-initialize from the minimum reproducer, and/or after moving
package-enable-at-startup to early-init.el makes the bug unreproducible.
If nothing else, it seems like our src:emacs might need a NEWS entry on
the topic, but that said, my suspicion is that lsp-mode could be more
defensive.
Cheers,
Nicholas
So what you're saying is that in Emacs >= 27, I don't need the package-initialize anymore and that will fix my bug?
Antoine Beaupré <anarcat@debian.org> writes: [snip] Yup, you don't need to manually call package-initialize anymore; also, please see the note about package-enable-at-startup, because that variable "must" now be set in the new early-init.el. AFAICT These easy config changes are normal major version migration stuff, but I'm not sure if they'll be enough to solve your bug. Definitely worth a shot though! Cheers, Nicholas
Hi Nicholas, Чт 29 апр 2021 @ 13:54 Nicholas D Steeves <nsteeves@gmail.com>: That's interesting! Thanks for your input. I've tried Antoine's minimal configuration and can confirm that commenting out (package-initialize) resolves the problem. So, it really means that lsp-mode has an autoload cookie which when evaluated twice causes the bug. But now I wonder to which package should we assign the bug report, lsp-mode, emacs, some other package?.. Cheers! Lev
I still need to get to the office to confirm the fix, but this totally
makes sense. I have a very old Emacs configuration, which I've been
carrying for over two decades at this point. Cruft is bound to creep up
in there, and I'm actually surprised things still work in any meaningful
way. :)
I'm still kind of confused. What's the proper way to (say) setup package
repositories and then `use-package'?
In other words, what's the modern equivalent of this in my
`.emacs.d/init.el`?
(when (require 'package nil t)
(setq-default
load-prefer-newer t
package-enable-at-startup nil)
(when (< emacs-major-version 27)
(package-initialize))
(setq package-archives '(("gnu" . "https://elpa.gnu.org/packages/")
("melpa" . "https://melpa.org/packages/")))
;; in elpa-use-package debian package since stretch
(unless (package-installed-p 'use-package)
(package-refresh-contents)
(package-install 'use-package)))
(eval-when-compile
(require 'use-package)
(setq-default
use-package-always-defer nil
use-package-always-ensure t))
Note that I added this `(when (< emacs-major-version 27)' blob to try to
workaround the bug. But now it seems that this packaging stuff might
belong to early-init.el? What if I want this config to still work in
Emacs 26?
Thanks for holding my hand through the new millenia. ;)
a.
So removing the (package-initialize) bit doesn't work here, i.e. I still get the bug. Not sure why *you* are getting something different here, but I still don't have a good workaround. I have no idea.
Hi Antoine, I had started on a draft of this email before receiving your latest update; however, I the info below is still relevant. Antoine Beaupré <anarcat@debian.org> writes: :-) I feel that way about some of my config too! And I think you'll agree that Emacs is great because it accommodates this, and that its config and customisation becomes more of a "story" than the way some people are using "story" as a synonym for "new user experience". It's tangential to this bug, but I'm curious what you think about the new trendy "literate programming" style configs? (I'm not sure if/when I will switch to one, but I think it's a cool idea!): https://harryrschwartz.com/2016/02/15/switching-to-a-literate-emacs-configuration https://raw.githubusercontent.com/sachac/.emacs.d/gh-pages/Sacha.org If I understand the new Emacs init process correctly, then a simplified form describing the init process looks something like this: (lambda () (load early-init.el) ;; I suspect the init for the UI goes here (package-initialize) ;; automatic (mapc 'load (list of all supported init.el locations))) I'm not a `use-package` user, but I think use-package stuff is supposed to continue be configured from a supported init.el location...rationale being that `use-package` seems like it ought to be post-`package-initialize`. Please see note in previous emails about the location where `package-enable-at-startup` *must* be set. There may also be other bits of your init.el that must now be moved to early-init.el. Sorry, I don't have a list... I trust the docstrings, so I don't think this is an optional thing that can be ignored. There are a couple of ways to do this, take your pick ;-) 1. Use early-init.el on Emacs 27 hosts and add special cases everywhere it may be required in init.el (icky, imho!) * Note, init.el will need at least one special case for `package-initialize`. 2. Move what must go in early-init.el to that file, and then (load early-init.el) at the top of init.el for emacs < 27 hosts. * I wonder if there will be corner case breakage with this? 3. If you don't need Emacs 25, that means you're on buster, which means Emacs 27 is available from buster-backports. * This is the option I chose, to keep my config as simple as possible. * Please note there's a IMHO RC (to backports) bug in the declared dependencies. IIRC the workaround is to manually 'apt install -t buster-backports emacs-common'. It might have also been this issue: https://lists.debian.org/debian-backports/2021/03/msg00012.html Sorry, I can't clearly remember... * Buster-backports is also missing emacs-common-non-dfsg for Emacs 27 :-( Luckily it's arch:all so can be installed from unstable. * Additionally, take care to either remove elpa-org, or upgrade it to the version in unstable, since IIRC the version bundled with Emacs 27 is newer than the version in buster. Anytime! Oh, one more thing, I've read about how old elc files (in $HOME) have caused problems this release, so it's probably also a good idea to erase them all and re[byte]compile them. Cheers, Nicholas
Hi Lev, Lev Lamberov <dogsleg@debian.org> writes: Thanks! And you're welcome :-) Thank you for confirming this. Hmm...let's start with lsp-mode, which should defend against double evaluation of an autoload cookie. I'm CCing Rob in case there's something our emacs package could do (like release notes, or some kind of init.el checks)...reason being, all users comes from prior Debian releases will have (package-initialize) in their init.el files, and there's an undefined but possibly huge subset of these users whose configs may be broken by the new requirements to move a portion of their configs to init-early.el. We can always clone, reassign, and retitle as necessary. Arguably this is just a normal "adapt to the new Emacs version" stuff, but I feel like it might not be sufficiently well documented (ie: that the fixes are "lore" rather than "documentation"), and I also feel like we might get a lot of bug reports from users who aren't aware of these changes. To be completely honest, I'm not sure what the "balanced" option is for this issue. Rob, does this issue sound significant enough that we (in Debian) need to do something more than usual? Cheers, Nicholas