Description of problem: I can't install a package from a local Emacs lisp buffer using `M-x package-install-from-buffer` because I get a "Can't read whole string". I debugged the issue down to `package-read-from-string`. The issue seems to *specifically* be when `package-read-from-string` has been compiled by the native compiler since when I manually `eval-defun` the code of `package-read-from-string` it behaves like expected again. Version-Release number of selected component (if applicable): 30.1 How reproducible: Always. Steps to Reproduce: 1. Run `M-: (package-read-from-string "((emacs \"29.4\"))")` Actual results: Debugger entered--Lisp error: (error "Can’t read whole string") error("Can't read whole string") package-read-from-string("((emacs \"29.4\"))") eval((package-read-from-string "((emacs \"29.4\"))") t) #f(compiled-function () #<bytecode 0x13736ecb77fc394>)() #f(compiled-function () #<bytecode -0x5db3e1955cb81d1>)() eval-expression((package-read-from-string "((emacs \"29.4\"))") nil nil 127) funcall-interactively(eval-expression (package-read-from-string "((emacs \"29.4\"))") nil nil 127) command-execute(eval-expression) Expected results: ((emacs "29.4")) Workaround: Go to the definition of `package-read-from-string` and `eval-defun`.
After reading debbugs for a bit I *believe* the upstream issue(s) are: - https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63288 - https://debbugs.gnu.org/cgi/bugreport.cgi?bug=74771 - https://debbugs.gnu.org/cgi/bugreport.cgi?bug=76523 … and that a workaround is to build with `make -j1` instead. It's supposedly fixed on master in the following commit: 53a5dada413662389a17c551a00d215e51f5049f Fix compilation errors due to insufficient compiler safety (bug#63288) … and as can be seen at the end of the discussions in the bugs linked above they're waiting for response from Andrea Corallo on whether to backport the fix to Emacs 30.
The fix has since been approved and cherry-picked to the emacs-30 branch: - https://debbugs.gnu.org/cgi/bugreport.cgi?bug=76523 See commit 6cac92928a99a2cf33aeeeddf295cf981750391c
FEDORA-2025-68774455f4 (emacs-30.1-11.fc42) has been submitted as an update to Fedora 42. https://bodhi.fedoraproject.org/updates/FEDORA-2025-68774455f4
FEDORA-2025-68774455f4 has been pushed to the Fedora 42 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-68774455f4` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-68774455f4 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
I'm not sure if I have the power to give karma, but I can confirm that https://src.fedoraproject.org/rpms/emacs/c/c65031ee31dbe44c66af2e17511bffb2fa6038ee fixed the issue (at least for me)! Thanks a lot!
(In reply to Mattias Bengtsson from comment #5) > I'm not sure if I have the power to give karma There is an explanation of how to do it at https://fedoraproject.org/wiki/QA:Updates_Testing#Using_the_web_interface
FEDORA-2025-68774455f4 (emacs-30.1-11.fc42) has been pushed to the Fedora 42 stable repository. If problem still persists, please make note of it in this bug report.