GNU bug report logs - #79997
31.0.50; prepare-user-lisp error on startup

Previous Next

To reply to this bug, email your comments to 79997 AT debbugs.gnu.org.
There is no need to reopen the bug first.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Roi Martin <jroi.martin <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50; prepare-user-lisp error on startup
Date: Sat, 13 Dec 2025 10:12:03 +0100

Emacs fails with the following error on startup:

  Error while compiling: (void-function byte-recompile-file)

Steps to reproduce:

  1. mkdir -p /tmp/emacs-bug/user-lisp
  2. touch /tmp/emacs-bug/init.el /tmp/emacs-bug/user-lisp/foo.el
  3. emacs --init-directory=/tmp/emacs-bug/

Commit:

  41ffeaec15b9 "Update from Gnulib by running admin/merge-gnulib"

It seems that when `prepare-user-lisp' calls `byte-recompile-file', this
function has not been loaded yet.

        Roi

Message #8 received at 79997 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Roi Martin <jroi.martin <at> gmail.com>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 79997 <at> debbugs.gnu.org, philipk <at> posteo.net
Subject: Re: bug#79997: 31.0.50; prepare-user-lisp error on startup
Date: Sat, 13 Dec 2025 11:38:19 +0200

> Cc: philipk <at> posteo.net
> From: Roi Martin <jroi.martin <at> gmail.com>
> Date: Sat, 13 Dec 2025 10:12:03 +0100
> 
> Emacs fails with the following error on startup:
> 
>   Error while compiling: (void-function byte-recompile-file)
> 
> Steps to reproduce:
> 
>   1. mkdir -p /tmp/emacs-bug/user-lisp
>   2. touch /tmp/emacs-bug/init.el /tmp/emacs-bug/user-lisp/foo.el
>   3. emacs --init-directory=/tmp/emacs-bug/
> 
> Commit:
> 
>   41ffeaec15b9 "Update from Gnulib by running admin/merge-gnulib"
> 
> It seems that when `prepare-user-lisp' calls `byte-recompile-file', this
> function has not been loaded yet.

byte-recompile-file is not autoloaded.  I think We need either to
autoload it or manually (require 'bytecomp) before invoking it in
startup.el.

Message #11 received at 79997 <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79997 <at> debbugs.gnu.org, Roi Martin <jroi.martin <at> gmail.com>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#79997: 31.0.50; prepare-user-lisp error on startup
Date: Sat, 13 Dec 2025 11:08:38 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Cc: philipk <at> posteo.net
>> From: Roi Martin <jroi.martin <at> gmail.com>
>> Date: Sat, 13 Dec 2025 10:12:03 +0100
>> 
>> Emacs fails with the following error on startup:
>> 
>>   Error while compiling: (void-function byte-recompile-file)
>> 
>> Steps to reproduce:
>> 
>>   1. mkdir -p /tmp/emacs-bug/user-lisp
>>   2. touch /tmp/emacs-bug/init.el /tmp/emacs-bug/user-lisp/foo.el
>>   3. emacs --init-directory=/tmp/emacs-bug/
>> 
>> Commit:
>> 
>>   41ffeaec15b9 "Update from Gnulib by running admin/merge-gnulib"
>> 
>> It seems that when `prepare-user-lisp' calls `byte-recompile-file', this
>> function has not been loaded yet.
>
> byte-recompile-file is not autoloaded.  I think We need either to
> autoload it or manually (require 'bytecomp) before invoking it in
> startup.el.

I have already heard about this issue, but I haven't been able to
reproduce it myself which confuses me.  Do you have any ideas why some
people might be running into this while others aren't?

Message #14 received at 79997 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: 79997 <at> debbugs.gnu.org, jroi.martin <at> gmail.com, monnier <at> iro.umontreal.ca
Subject: Re: bug#79997: 31.0.50; prepare-user-lisp error on startup
Date: Sat, 13 Dec 2025 13:17:16 +0200

> From: Philip Kaludercic <philipk <at> posteo.net>
> Cc: Roi Martin <jroi.martin <at> gmail.com>,  Stefan Monnier
>  <monnier <at> iro.umontreal.ca>,  79997 <at> debbugs.gnu.org
> Date: Sat, 13 Dec 2025 11:08:38 +0000
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> Cc: philipk <at> posteo.net
> >> From: Roi Martin <jroi.martin <at> gmail.com>
> >> Date: Sat, 13 Dec 2025 10:12:03 +0100
> >> 
> >> Emacs fails with the following error on startup:
> >> 
> >>   Error while compiling: (void-function byte-recompile-file)
> >> 
> >> Steps to reproduce:
> >> 
> >>   1. mkdir -p /tmp/emacs-bug/user-lisp
> >>   2. touch /tmp/emacs-bug/init.el /tmp/emacs-bug/user-lisp/foo.el
> >>   3. emacs --init-directory=/tmp/emacs-bug/
> >> 
> >> Commit:
> >> 
> >>   41ffeaec15b9 "Update from Gnulib by running admin/merge-gnulib"
> >> 
> >> It seems that when `prepare-user-lisp' calls `byte-recompile-file', this
> >> function has not been loaded yet.
> >
> > byte-recompile-file is not autoloaded.  I think We need either to
> > autoload it or manually (require 'bytecomp) before invoking it in
> > startup.el.
> 
> I have already heard about this issue, but I haven't been able to
> reproduce it myself which confuses me.  Do you have any ideas why some
> people might be running into this while others aren't?

I don't know.  I just tried the above recipe myself, and I don't see
the messages.  But OTOH /tmp/emacs-bug/user-lisp/foo.el isn't
byte-compiled, either.  So I'm guessing that in some situations we
don't invoke byte-recompile-file, and in others we do.  The call to
byte-recompile-file is conditioned by just-activate being nil, so
maybe that's the reason?

In any case, it should be quite clear that we cannot invoke a function
that is not preloaded and not autoloaded without requiring its
package, can we?

Message #17 received at 79997 <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: Roi Martin <jroi.martin <at> gmail.com>
Cc: 79997 <at> debbugs.gnu.org
Subject: Re: bug#79997: 31.0.50; prepare-user-lisp error on startup
Date: Sat, 13 Dec 2025 11:18:13 +0000

[Message part 1 (text/plain, inline)]

Roi Martin <jroi.martin <at> gmail.com> writes:

> Emacs fails with the following error on startup:
>
>   Error while compiling: (void-function byte-recompile-file)
>
> Steps to reproduce:
>
>   1. mkdir -p /tmp/emacs-bug/user-lisp
>   2. touch /tmp/emacs-bug/init.el /tmp/emacs-bug/user-lisp/foo.el
>   3. emacs --init-directory=/tmp/emacs-bug/
>
> Commit:
>
>   41ffeaec15b9 "Update from Gnulib by running admin/merge-gnulib"
>
> It seems that when `prepare-user-lisp' calls `byte-recompile-file', this
> function has not been loaded yet.
>
>         Roi

Can you see if applying this change makes any difference:

[Message part 2 (text/x-patch, inline)]

diff --git a/lisp/startup.el b/lisp/startup.el
index c455eb73814..7804ab42c8c 100644
--- a/lisp/startup.el
+++ b/lisp/startup.el
@@ -1236,6 +1236,9 @@ user-lisp-ignored-directories
   :type '(choice (repeat (string :tag "Directory name")))
   :version "31.1")
 
+(declare-function byte-recompile-file "bytecomp"
+                  (filename &optional force arg load))
+
 (defun prepare-user-lisp (&optional just-activate autoload-file force)
   "Byte-compile, scrape autoloads and prepare files in `user-lisp-directory'.
 Write the autoload file to AUTOLOAD-FILE.  If JUST-ACTIVATE is non-nil,
@@ -1246,6 +1249,7 @@ prepare-user-lisp
 re-create the entire autoload file and byte-compile everything
 unconditionally."
   (interactive (list nil nil current-prefix-arg))
+  (unless just-activate (require 'bytecomp))
   (unless (file-directory-p user-lisp-directory)
     (error "No such directory: %S" user-lisp-directory))
   (unless autoload-file

[Message part 3 (text/plain, inline)]

I would also be interested to hear if you had any compiler warnings
without the `declare-function'?

Message #20 received at 79997 <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79997 <at> debbugs.gnu.org, jroi.martin <at> gmail.com, monnier <at> iro.umontreal.ca
Subject: Re: bug#79997: 31.0.50; prepare-user-lisp error on startup
Date: Sat, 13 Dec 2025 11:24:36 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Philip Kaludercic <philipk <at> posteo.net>
>> Cc: Roi Martin <jroi.martin <at> gmail.com>,  Stefan Monnier
>>  <monnier <at> iro.umontreal.ca>,  79997 <at> debbugs.gnu.org
>> Date: Sat, 13 Dec 2025 11:08:38 +0000
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> >> Cc: philipk <at> posteo.net
>> >> From: Roi Martin <jroi.martin <at> gmail.com>
>> >> Date: Sat, 13 Dec 2025 10:12:03 +0100
>> >> 
>> >> Emacs fails with the following error on startup:
>> >> 
>> >>   Error while compiling: (void-function byte-recompile-file)
>> >> 
>> >> Steps to reproduce:
>> >> 
>> >>   1. mkdir -p /tmp/emacs-bug/user-lisp
>> >>   2. touch /tmp/emacs-bug/init.el /tmp/emacs-bug/user-lisp/foo.el
>> >>   3. emacs --init-directory=/tmp/emacs-bug/
>> >> 
>> >> Commit:
>> >> 
>> >>   41ffeaec15b9 "Update from Gnulib by running admin/merge-gnulib"
>> >> 
>> >> It seems that when `prepare-user-lisp' calls `byte-recompile-file', this
>> >> function has not been loaded yet.
>> >
>> > byte-recompile-file is not autoloaded.  I think We need either to
>> > autoload it or manually (require 'bytecomp) before invoking it in
>> > startup.el.
>> 
>> I have already heard about this issue, but I haven't been able to
>> reproduce it myself which confuses me.  Do you have any ideas why some
>> people might be running into this while others aren't?
>
> I don't know.  I just tried the above recipe myself, and I don't see
> the messages.  But OTOH /tmp/emacs-bug/user-lisp/foo.el isn't
> byte-compiled, either.  So I'm guessing that in some situations we
> don't invoke byte-recompile-file, and in others we do.  The call to
> byte-recompile-file is conditioned by just-activate being nil, so
> maybe that's the reason?
>
> In any case, it should be quite clear that we cannot invoke a function
> that is not preloaded and not autoloaded without requiring its
> package, can we?

I agree that it doesn't make any sense, but on my system it works --
even without the patch I sent to Roi -- and I get a .elc file generated
next to an .el file.  This seems to point to some deeper issue that
exceeds my current familiarity with the startup process...

Message #23 received at 79997 <at> debbugs.gnu.org (full text, mbox):

From: Roi Martin <jroi.martin <at> gmail.com>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: 79997 <at> debbugs.gnu.org
Subject: Re: bug#79997: 31.0.50; prepare-user-lisp error on startup
Date: Sat, 13 Dec 2025 15:03:55 +0100

Philip Kaludercic <philipk <at> posteo.net> writes:

> Can you see if applying this change makes any difference:
>
> diff --git a/lisp/startup.el b/lisp/startup.el
> index c455eb73814..7804ab42c8c 100644
> --- a/lisp/startup.el
> +++ b/lisp/startup.el
> @@ -1236,6 +1236,9 @@ user-lisp-ignored-directories
>    :type '(choice (repeat (string :tag "Directory name")))
>    :version "31.1")
>  
> +(declare-function byte-recompile-file "bytecomp"
> +                  (filename &optional force arg load))
> +
>  (defun prepare-user-lisp (&optional just-activate autoload-file force)
>    "Byte-compile, scrape autoloads and prepare files in `user-lisp-directory'.
>  Write the autoload file to AUTOLOAD-FILE.  If JUST-ACTIVATE is non-nil,
> @@ -1246,6 +1249,7 @@ prepare-user-lisp
>  re-create the entire autoload file and byte-compile everything
>  unconditionally."
>    (interactive (list nil nil current-prefix-arg))
> +  (unless just-activate (require 'bytecomp))
>    (unless (file-directory-p user-lisp-directory)
>      (error "No such directory: %S" user-lisp-directory))
>    (unless autoload-file

The patch seems to fix the issue.

> I would also be interested to hear if you had any compiler warnings
> without the `declare-function'?

I don't see any compiler warning after removing the `declare-function'
call.

        Roi

Message #26 received at 79997 <at> debbugs.gnu.org (full text, mbox):

From: Roi Martin <jroi.martin <at> gmail.com>
To: Philip Kaludercic <philipk <at> posteo.net>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 79997 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#79997: 31.0.50; prepare-user-lisp error on startup
Date: Sat, 13 Dec 2025 15:22:58 +0100

Philip Kaludercic <philipk <at> posteo.net> writes:

>>> I have already heard about this issue, but I haven't been able to
>>> reproduce it myself which confuses me.  Do you have any ideas why some
>>> people might be running into this while others aren't?
>>
>> I don't know.  I just tried the above recipe myself, and I don't see
>> the messages.  But OTOH /tmp/emacs-bug/user-lisp/foo.el isn't
>> byte-compiled, either.  So I'm guessing that in some situations we
>> don't invoke byte-recompile-file, and in others we do.  The call to
>> byte-recompile-file is conditioned by just-activate being nil, so
>> maybe that's the reason?
>>
>> In any case, it should be quite clear that we cannot invoke a function
>> that is not preloaded and not autoloaded without requiring its
>> package, can we?
>
> I agree that it doesn't make any sense, but on my system it works --
> even without the patch I sent to Roi -- and I get a .elc file generated
> next to an .el file.  This seems to point to some deeper issue that
> exceeds my current familiarity with the startup process...

Just in case it helps, here you have the system info as reported by 'M-x
report-emacs-bug' after following the recipe in the bug report.  Also,
Emacs was built with:

  ./autogen.sh && ./configure && make -j8

And run from the source tree.

In GNU Emacs 31.0.50 (build 15, x86_64-pc-linux-gnu, GTK+ Version
 3.24.51, cairo version 1.18.4) of 2025-12-13 built on wopr
Repository revision: 41ffeaec15b9a0f052de2d2e5eab23302c4ce46b
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12401009
System Description: Fedora Linux 43 (Workstation Edition)

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG
LCMS2 LIBSELINUX LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY
PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS
TREE_SITTER WEBP X11 XDBE XIM XINERAMA XINPUT2 XPM XRANDR GTK3 ZLIB

Important settings:
  value of $LC_MONETARY: en_IE.UTF-8
  value of $LC_NUMERIC: en_IE.UTF-8
  value of $LC_TIME: en_IE.UTF-8
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  minibuffer-nonselected-mode: t
  minibuffer-regexp-mode: t
  buffer-read-only: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util time-date mm-decode mm-bodies mm-encode mailabbrev
gmm-utils mailheader cl-loaddefs cl-lib sendmail mail-parse rfc2231
rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils compile
text-property-search comint subr-x ansi-osc ansi-color ring comp-run
bytecomp byte-compile comp-common rx loaddefs-gen generate-lisp-file
lisp-mnt radix-tree rmc iso-transl tooltip cconv eldoc paren electric
uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
term/x-win x-win term/common-win x-dnd touch-screen tool-bar dnd fontset
image regexp-opt fringe tabulated-list replace newcomment text-mode
lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch
easymenu timer select scroll-bar mouse jit-lock font-lock syntax
font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting cairo gtk
x-toolkit xinput2 x multi-tty move-toolbar make-network-process
tty-child-frames native-compile emacs)

Memory information:
((conses 16 62254 9638) (symbols 48 6903 0) (strings 32 18455 3927)
 (string-bytes 1 604415) (vectors 16 12769)
 (vector-slots 8 152025 10178) (floats 8 22 2) (intervals 56 381 13)
 (buffers 1064 12))

Message #29 received at 79997 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 79997 <at> debbugs.gnu.org, jroi.martin <at> gmail.com
Subject: Re: bug#79997: 31.0.50; prepare-user-lisp error on startup
Date: Sat, 13 Dec 2025 10:34:06 -0500

> I agree that it doesn't make any sense, but on my system it works --
> even without the patch I sent to Roi -- and I get a .elc file generated
> next to an .el file.  This seems to point to some deeper issue that
> exceeds my current familiarity with the startup process...

Maybe in your setup the byte compiler gets loaded for some other reason
(e.g. cl-generic dispatch can do that).


        Stefan

Message #32 received at 79997 <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 79997 <at> debbugs.gnu.org, jroi.martin <at> gmail.com
Subject: Re: bug#79997: 31.0.50; prepare-user-lisp error on startup
Date: Sat, 13 Dec 2025 15:59:19 +0000

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> Maybe in your setup the byte compiler gets loaded for some other reason
> (e.g. cl-generic dispatch can do that).

It could be that this is a side-effect of some package I have installed!
The User Lisp directory is processed after the packages are activated,
so this might be a hint in what direction to investigate.

Message #35 received at 79997 <at> debbugs.gnu.org (full text, mbox):

From: Roi Martin <jroi.martin <at> gmail.com>
To: Philip Kaludercic <philipk <at> posteo.net>, Stefan Monnier
 <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 79997 <at> debbugs.gnu.org
Subject: Re: bug#79997: 31.0.50; prepare-user-lisp error on startup
Date: Sat, 13 Dec 2025 21:29:38 +0100

Philip Kaludercic <philipk <at> posteo.net> writes:

> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>
>> Maybe in your setup the byte compiler gets loaded for some other reason
>> (e.g. cl-generic dispatch can do that).
>
> It could be that this is a side-effect of some package I have installed!
> The User Lisp directory is processed after the packages are activated,
> so this might be a hint in what direction to investigate.

Then you should be able to reproduce the bug with my recipe, right?  It
creates a clean init directory.

        Roi

Message #38 received at 79997 <at> debbugs.gnu.org (full text, mbox):

From: Roi Martin <jroi.martin <at> gmail.com>
To: Philip Kaludercic <philipk <at> posteo.net>, Stefan Monnier
 <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 79997 <at> debbugs.gnu.org
Subject: Re: bug#79997: 31.0.50; prepare-user-lisp error on startup
Date: Sat, 13 Dec 2025 21:48:45 +0100

Roi Martin <jroi.martin <at> gmail.com> writes:

> Philip Kaludercic <philipk <at> posteo.net> writes:
>
>> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>>
>>> Maybe in your setup the byte compiler gets loaded for some other reason
>>> (e.g. cl-generic dispatch can do that).
>>
>> It could be that this is a side-effect of some package I have installed!
>> The User Lisp directory is processed after the packages are activated,
>> so this might be a hint in what direction to investigate.
>
> Then you should be able to reproduce the bug with my recipe, right?  It
> creates a clean init directory.

Maybe something in site-start.el or default.el?

        Roi

Message #43 received at 79997-done <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: Roi Martin <jroi.martin <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Stefan Monnier <monnier <at> iro.umontreal.ca>,
 79997-done <at> debbugs.gnu.org
Subject: Re: bug#79997: 31.0.50; prepare-user-lisp error on startup
Date: Sun, 14 Dec 2025 15:54:47 +0000

Roi Martin <jroi.martin <at> gmail.com> writes:

> Roi Martin <jroi.martin <at> gmail.com> writes:
>
>> Philip Kaludercic <philipk <at> posteo.net> writes:
>>
>>> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>>>
>>>> Maybe in your setup the byte compiler gets loaded for some other reason
>>>> (e.g. cl-generic dispatch can do that).
>>>
>>> It could be that this is a side-effect of some package I have installed!
>>> The User Lisp directory is processed after the packages are activated,
>>> so this might be a hint in what direction to investigate.
>>
>> Then you should be able to reproduce the bug with my recipe, right?  It
>> creates a clean init directory.

I actually missed that in your first message, but running it I could
confirm that the issue also exists on my end.  I have pushed the
proposed change to master and will close the report.

Thanks a lot for testing and reporting the issues back!

> Maybe something in site-start.el or default.el?
>
>         Roi

Message #46 received at 79997-done <at> debbugs.gnu.org (full text, mbox):

From: Roi Martin <jroi.martin <at> gmail.com>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Stefan Monnier <monnier <at> iro.umontreal.ca>,
 79997-done <at> debbugs.gnu.org
Subject: Re: bug#79997: 31.0.50; prepare-user-lisp error on startup
Date: Mon, 15 Dec 2025 14:12:00 +0100

Philip Kaludercic <philipk <at> posteo.net> writes:

> I have pushed the proposed change to master and will close the report.

Thanks!

        Roi

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.