Bug#987683: crashes with "Wrong type argument: (or eieio-object class), nil, obj"
Hi Lev, Lev Lamberov writes: > That's interesting! Thanks for your input. Thanks! And you're welcome :-) > 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. > Thank you for confirming this. > But now I wonder to which package should we assign the bug report, > lsp-mode, emacs, some other package?.. > 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 signature.asc Description: PGP signature
Bug#987683: crashes with "Wrong type argument: (or eieio-object class), nil, obj"
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é writes:
> 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 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
> I'm still kind of confused. What's the proper way to (say) setup package
> repositories and then `use-package'?
>
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`.
> 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)
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.
> (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?
>
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.
> Thanks for holding my hand through the new millenia. ;)
>
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
signature.asc
Description: PGP signature
Bug#987683: crashes with "Wrong type argument: (or eieio-object class), nil, obj"
On 2021-04-30 10:23:14, Lev Lamberov wrote: > Hi Nicholas, > > Чт 29 апр 2021 @ 13:54 Nicholas D Steeves : > >> Antoine Beaupré writes: >> >>> 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) >> >> 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. > > 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. 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. > But now I wonder to which package should we assign the bug report, > lsp-mode, emacs, some other package?.. I have no idea. -- La dictature c'est ferme ta gueule. La démocratie c'est cause toujours! - Jean-Louis Barrault
Bug#987683: crashes with "Wrong type argument: (or eieio-object class), nil, obj"
On 2021-04-29 20:38:53, Nicholas D. Steeves wrote:
> Antoine Beaupré writes:
>> On 2021-04-29 13:54:05, Nicholas D. Steeves wrote:
> [snip]
>>> 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.
>>
>> So what you're saying is that in Emacs >= 27, I don't need the
>> package-initialize anymore and that will fix my bug?
>>
>
> 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!
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.
--
Arguing for surveillance because you have nothing to hide is no
different than making the claim, "I don't care about freedom of speech
because I have nothing to say."
- Edward Snowden
Bug#987683: crashes with "Wrong type argument: (or eieio-object class), nil, obj"
Hi Nicholas, Чт 29 апр 2021 @ 13:54 Nicholas D Steeves : > Antoine Beaupré writes: > >> 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) > > 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. 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
Bug#987683: crashes with "Wrong type argument: (or eieio-object class), nil, obj"
Antoine Beaupré writes: > On 2021-04-29 13:54:05, Nicholas D. Steeves wrote: [snip] >> 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. > > So what you're saying is that in Emacs >= 27, I don't need the > package-initialize anymore and that will fix my bug? > 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 signature.asc Description: PGP signature
Bug#987683: crashes with "Wrong type argument: (or eieio-object class), nil, obj"
On 2021-04-29 13:54:05, Nicholas D. Steeves wrote: > Hi Antoine and Lev! > > Antoine Beaupré writes: > >> 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) > > 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. So what you're saying is that in Emacs >= 27, I don't need the package-initialize anymore and that will fix my bug? -- Like slavery and apartheid, poverty is not natural. It is man-made and it can be overcome and eradicated by the actions of human beings. Overcoming poverty is not a gesture of charity. It is an act of justice. - Nelson Mandela
Bug#987683: crashes with "Wrong type argument: (or eieio-object class), nil, obj"
Hi Antoine and Lev! Antoine Beaupré writes: > 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) 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 signature.asc Description: PGP signature
Bug#987683: crashes with "Wrong type argument: (or eieio-object class), nil, obj"
Ср 28 апр 2021 @ 14:30 Antoine Beaupré :
> On 2021-04-28 23:07:26, Lev Lamberov wrote:
>> Ср 28 апр 2021 @ 11:44 Antoine Beaupré :
>>
>>> On 2021-04-28 20:34:26, Lev Lamberov wrote:
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
>>>
>>> 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...
>>
>> 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.
>
> 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.
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
Bug#987683: crashes with "Wrong type argument: (or eieio-object class), nil, obj"
On 2021-04-28 23:07:26, Lev Lamberov wrote:
> Ср 28 апр 2021 @ 11:44 Antoine Beaupré :
>
>> On 2021-04-28 20:34:26, Lev Lamberov wrote:
>>> 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
>>
>> 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...
>
> 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.
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.
--
Gods don't like people not doing much work. People who aren't busy all
the time might start to think.
- Terry Pratchett, Small Gods
Bug#987683: crashes with "Wrong type argument: (or eieio-object class), nil, obj"
Ср 28 апр 2021 @ 11:44 Antoine Beaupré : > On 2021-04-28 20:34:26, Lev Lamberov wrote: >> 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 > > 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... 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
Bug#987683: crashes with "Wrong type argument: (or eieio-object class), nil, obj"
On 2021-04-28 20:34:26, Lev Lamberov wrote: > 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 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. -- There has been only one Christian. They caught him and crucified him -- early. - Mark Twain
Bug#987683: crashes with "Wrong type argument: (or eieio-object class), nil, obj"
On 2021-04-28 20:34:26, Lev Lamberov wrote: > Ср 28 апр 2021 @ 08:50 Antoine Beaupré : > >> Control: severity -1 normal >> >> On 2021-04-28 09:00:46, Lev Lamberov wrote: >>> Hi Antoine, >>> >>> Вт 27 апр 2021 @ 13:53 Antoine Beaupre : >>> 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: >> >> Oh interesting! Maybe that's why it works, since the bytecode is older? > > 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). Mine says the same. [...] >>> So, may it be a bug in dh-elpa or GNU Emacs itself? >> >> 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. > > 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 Thanks, I'll try that next. -- Never attribute to malice that which can be adequately explained by stupidity, but don't rule out malice. - Albert Einstein
Bug#987683: crashes with "Wrong type argument: (or eieio-object class), nil, obj"
Ср 28 апр 2021 @ 08:50 Antoine Beaupré : > Control: severity -1 normal > > On 2021-04-28 09:00:46, Lev Lamberov wrote: >> Hi Antoine, >> >> Вт 27 апр 2021 @ 13:53 Antoine Beaupre : >> 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: > > Oh interesting! Maybe that's why it works, since the bytecode is older? 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). >> ``` >> 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. > > 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. 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. >> So, may it be a bug in dh-elpa or GNU Emacs itself? > > 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. 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
Bug#987683: crashes with "Wrong type argument: (or eieio-object class), nil, obj"
Control: severity -1 normal On 2021-04-28 09:00:46, Lev Lamberov wrote: > Hi Antoine, > > Вт 27 апр 2021 @ 13:53 Antoine Beaupre : > >> Package: elpa-esup >> Version: 0.7.1-3 >> Severity: grave >> Tags: upstream >> >> 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). > > Thanks for reporting, investigating and forwarding! > > Is it a fresh install of elpa-esup? Yes, installed from the Debian package in Bullseye. > 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: Oh interesting! Maybe that's why it works, since the bytecode is older? > ``` > 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. 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. [...] > So, may it be a bug in dh-elpa or GNU Emacs itself? 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. -- While the creative works from the 16th century can still be accessed and used by others, the data in some software programs from the 1990s is already inaccessible. - Lawrence Lessig
Bug#987683: crashes with "Wrong type argument: (or eieio-object class), nil, obj"
Hi Antoine, Вт 27 апр 2021 @ 13:53 Antoine Beaupre : > Package: elpa-esup > Version: 0.7.1-3 > Severity: grave > Tags: upstream > > 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). Thanks for reporting, investigating and forwarding! 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
Bug#987683: crashes with "Wrong type argument: (or eieio-object class), nil, obj"
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
Bug#987683: crashes with "Wrong type argument: (or eieio-object class), nil, obj"
Package: elpa-esup Version: 0.7.1-3 Severity: grave Tags: upstream 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). -- System Information: Debian Release: 11.0 APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing-debug'), (500, 'testing'), (1, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-6-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages elpa-esup depends on: ii dh-elpa-helper 2.0.8 ii emacsen-common 3.0.4 Versions of packages elpa-esup recommends: ii emacs 1:27.1+1-3.1 ii emacs-gtk [emacs] 1:27.1+1-3.1 elpa-esup suggests no packages. -- debconf-show failed
