GNU bug report logs - #73855
[PATCH] * lisp/autorevert.el: Avoid reverting buffer in short time

Previous Next

Full log

View this message in rfc822 format

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Lin Sun <sunlin7.mail <at> gmail.com>
Cc: 73855-done <at> debbugs.gnu.org
Subject: bug#73855: [BUG] Error: void-function (rx) during generating autoloads for python.el when building from source
Date: Sun, 17 Nov 2024 06:08:07 -0800

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

>> From: Lin Sun <sunlin7.mail <at> gmail.com>
>> Date: Wed, 13 Nov 2024 17:13:14 +0000
>> Cc: 73855 <at> debbugs.gnu.org
>>
>> Thanks for replying, the error happened when I compiled the master
>> branch (a7400cb8810) on Ubuntu 20.04, clang-20, libgccjit-14.
>>
>> I spent more than 1 hours to search what caused the issue on my local
>> but didn't find the root cause, clean up and rebuild didn't help, so I
>> posted the error messages to mail list for searching helping.
>> This morning I checked out the latest master branch and started a
>> fresh building and everything works perfectly.
>>
>> The issue should be my local issue (maybe related to some environment
>> variables or dependent libraries). I'm still keeping my eyes on it,
>> and will investigate the root cause if it happens again.
>>
>> Please close this ticket, thanks, appreciate it!
>
> Stefan, can you please take a look?  Should python.el require rx due
> to this change?  If not, feel free to close.

I can't currently see that python.el should need to require rx due to
2f485e68ff96, no.  AFAICT, the `rx` macro is autoloaded, and the
defconst we put in loaddefs.el is then correctly converted to a string
in loaddefs.elc before dumping.  I also see that `(featurep 'rx)` is nil
in emacs -Q.  Finally, I can't reproduce the error in the OP, nor does
it seem like Lin Sun is able to.

So I'll close this bug for now.  Please reopen if this issue pops up
again and we can perhaps take a second look.

BTW, Lin Sun, please open a new bug report for any new issues in future.
Here, I can see that we used Bug#73855 for two different issues, which
makes it harder to track and follow the discussion.  Thanks!

Previous Next

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