Description of problem: I can no longer open files specified on the command line with emacs after updating to the following packages today: emacs-common-1:28.2-1.fc37.x86_64 emacs-nox-1:28.2-1.fc37.x86_64 Version-Release number of selected component (if applicable): 1.28.2-1 How reproducible: Always Steps to Reproduce: 1. Specify a file to open in emacs in a terminal. E.g., emacs ~/path/to/file.txt Actual results: the file does not open and the following error is shown: Symbol’s function definition is void: regexp-opt-group Expected results: The file is opened in emacs. Additional info:
Can you please retry with `emacs -Q`? Because this still works for me (with and without `-Q`).
Same behavior with -Q as well.
Uh, that's weird. Do you have any emacs extensions installed via rpms? I.e. what's the output of `rpm -qa|grep emacs`?
$ rpm -qa|grep emacs emacs-filesystem-28.2-1.fc37.noarch emacs-common-28.2-1.fc37.x86_64 emacs-nox-28.2-1.fc37.x86_64
Seeing the same thing, this is 100% reproducible with a fresh install of F37. Emacs is dead in the water. Notably it does not reproduce after I copy over my .emacs
I can repro the issue both with and without my .emacs file.
Steps to repro: 1) install and update F37 (workstation or server, doesn't matter) 2) dnf install emacs-nox 3) emacs somefile
I played with this a bit more today, and the more I look at it the stranger it seems. A few new bits of (maybe?) information: 1) I was able to read the last message displayed before the error which is: Loading /usr/share/emacs/site-lisp/site-start.d/desktop-entry-mode-init.el (source)...done However, removing the package desktop-file-utils which provides that file does not make the error go away, so it doesn't seem to be at fault. Removing all the files in /usr/share/emacs/site-lisp also does not make the error go away. 2) --debug-init does nothing 3) The failure is 100% reproducible with a newly installed system, but it is starting to feel like some sort of race, as it sometimes reappears after going away for a while. Removing ~/.emacs.d seems to affect things. Files being opened and saved may affect things? Both of those datapoints are pretty speculative, but it's getting late here. As I'm sure is fairly obvious, I'm working a bit in the dark here. If there is additional data that would be helpful, I'm happy to try to gather it. This situation is super painful for someone who spends much of the day in emacs.
I strongly suspect that this has something to do with native compilation, because the respective function is probably coming from /usr/lib64/emacs/28.2/native-lisp/28.2-f4f2efda/preloaded/regexp-opt-d2355c94-5f9416fe.eln. I can reproduce this in a container as well and additionally, you don't even have to provide a filename as a parameter at all, just launching emacs will trigger this error. Unfortunately that's all that I got so far :-/
*** Bug 2161397 has been marked as a duplicate of this bug. ***
I encountered this bug too, and spent some time tracking down the cause... There are actually 3 bugs involved: 1) regexp-opt.elc breaks emacs-nox (might be an upstream emacs bug, still investigating...) 2) native-compiled files have incorrect timestamp (Fedora package bug) 3) native compilation as root removes source installed native-compilation files (probably also an upstream emacs bug) (2) above is the result of emacs.spec building emacs-gtk after emacs-nox, and install using that (including the byte-compiled files), but copies emacs-nox + native-compiled files from the earlier emacs-nox build. The result is the byte-compiled files from emacs-gtk have a later timestamp than the native-compiled files, and so are loaded instead. NOTE: this doesn't affect "preloaded" eln files (which are loaded with the emacs binary) - except regexp-opt which isn't actually preloaded by emacs-nox (it's preloaded only if x-create-frame is defined, see lisp/loadup.el in the source) Adding a simple touch to the *.eln files after the %build_install step in emacs.spec fixes emacs-nox to use the regexp-opt native file, and emacs-nox loads without error (and fast). ::: emacs.spec.diff: --- emacs.spec-orig 2022-12-31 03:23:10.000000000 -0800 +++ emacs.spec 2023-01-24 14:22:27.625037344 -0800 @@ -443,6 +443,8 @@ # remove exec permissions from eln files to prevent the debuginfo extractor from # trying to extract debuginfo from them find %{buildroot}%{_libdir}/ -name '*eln' -type f | xargs chmod -x +# ensure native files are newer than byte-code files +find %{buildroot}%{_libdir}/ -name '*eln' -type f | xargs touch %check appstream-util validate-relax --nonet %{buildroot}/%{_metainfodir}/*.metainfo.xml :::end (3) is actually what I encountered. It only affects emacs run as root: if the native files are out of date vs the byte-compiled ones, re-compilation will remove the system installed files (my system integrity scripts were discovering "missing" *.eln files) - my local site-start.d files were affecting the regular load and I didn't see (2) until I narrowed things down to a "clean install. I'm pretty sure even if native compiled files are rebuilt in .emacs.d/eln-cache, they shouldn't be removed from (quite possibly readonly) /usr/share/emacs... (1) is probably caused by some other preloaded file in emacs-nox using (regexp-opt-group) and assuming it's preloaded... If one removes regexp-opt.elc to force the use of the source (regexp-opt.el.gz), emacs loads fine. Again, still investigating that one. I may log bugs for (1) and (3), but probably with upstream first if I can confirm they are not intended behavior. The patch above at least gets emacs-nox working, and so is probably worth a package release.
Any chance we can get an updated package with this fix?
*** Bug 2164930 has been marked as a duplicate of this bug. ***
> The patch above at least gets emacs-nox working, and so is probably worth a package release. I've launched scratch builds with your change: - Rawhide: https://koji.fedoraproject.org/koji/taskinfo?taskID=96771500 - F37: https://koji.fedoraproject.org/koji/taskinfo?taskID=96771505 If they solve at least (2), then I'll make a new (real) build in Rawhide and will submit an update to F37.
BTW, I think the patch might also fix rhbz#2160547, so you might be able to remove the exec perms from eln files again if that has value...
The latest version of emacs that came in today's update (emacs-nox-1:28.2-3.fc37.x86_64, emacs-common-1:28.2-3.fc37.x86_64, emacs-filesystem-1:28.2-3.fc37.noarch) seems to have fixed the issue for me.
Fixed for me with the latest package as well. I've installed a couple of new machines and all have worked well.
This message is a reminder that Fedora Linux 37 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 37 on 2023-12-05. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '37'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 37 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 37 entered end-of-life (EOL) status on 2023-12-05. Fedora Linux 37 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.