Description of problem: Something seems to have gone deeply wrong with emacs-28.1-2.fc36.x86_64 + emacs-ess-18.10.2-6.fc36.noarch . My git EDITOR is emacs and I use it daily, so I know I last use emacs okay on 19th Jul. Now it is stuck at loading "/usr/share/emacs/site-lisp/site-start.d/ess-init.el" on start-up. It appeared that I upgraded from emacs-1:27.2-11.fc36.x86_64 to emacs-1:28.1-2.fc36.x86_64 on Wed 20 Jul 2022 21:41:39 BST. Anyway, now when emacs starts, it spawns multiple processes of - part of "ps -ax": --- 906049 pts/9 Sl+ 0:03 emacs 906114 pts/10 Ssl+ 0:00 /usr/bin/emacs --batch -l /tmp/emacs-async-comp-ess-custom-cyjHX9.el 906116 ? Ssl 0:00 /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-64656c6574652d63686172_delete_char_0-5DY1M9.el 906118 ? Ssl 0:00 /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-64656c6574652d63686172_delete_char_0-28lIdB.el 906120 ? Ssl 0:00 /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-64656c6574652d63686172_delete_char_0-SDZLyz.el 906122 ? Ssl 0:00 /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-64656c6574652d63686172_delete_char_0-7gy55Z.el 906124 ? Ssl 0:00 /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-64656c6574652d63686172_delete_char_0-rETxmu.el 906126 ? Ssl 0:00 /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-64656c6574652d63686172_delete_char_0-3JyVYc.el 906128 ? Ssl 0:00 /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-64656c6574652d63686172_delete_char_0-PWDGyM.el 906130 ? Ssl 0:00 /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-64656c6574652d63686172_delete_char_0-GKBwii.el 906132 ? Ssl 0:00 /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-64656c6574652d63686172_delete_char_0-GTxZDz.el 906134 ? Ssl 0:00 /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-64656c6574652d63686172_delete_char_0-NSU0BX.el 906142 ? Ssl 0:00 /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-64656c6574652d63686172_delete_char_0-uCZIZo.el 906143 ? Ssl 0:00 /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-64656c6574652d63686172_delete_char_0-im9bnO.el 906146 ? Ssl 0:00 /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-64656c6574652d63686172_delete_char_0-Ku1RsE.el 906147 ? Ssl 0:00 /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-64656c6574652d63686172_delete_char_0-BEQeze.el 906150 ? Ssl 0:00 /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-64656c6574652d63686172_delete_char_0-XFzriX.el 906151 ? Ssl 0:00 /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-64656c6574652d63686172_delete_char_0-qpt6l8.el 906154 ? Ssl 0:00 /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-64656c6574652d63686172_delete_char_0-CfxhW5.el 906155 ? Ssl 0:00 /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-64656c6574652d63686172_delete_char_0-QYBJmp.el 906158 ? Ssl 0:00 /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-64656c6574652d63686172_delete_char_0-0aH6Fx.el 906160 ? Ssl 0:00 /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-64656c6574652d63686172_delete_char_0-Q9xbFy.el 906162 ? Ssl 0:00 /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-64656c6574652d63686172_delete_char_0-k4xCVV.el 906164 ? Ssl 0:00 /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-64656c6574652d63686172_delete_char_0-alEGQa.el 906166 ? Ssl 0:00 /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-64656c6574652d63686172_delete_char_0-xK3Dbs.el 906168 ? Ssl 0:00 /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-64656c6574652d63686172_delete_char_0-B3HlMK.el 906170 ? Ssl 0:00 /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-64656c6574652d63686172_delete_char_0-AX4jqh.el 906172 ? Ssl 0:00 /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-64656c6574652d63686172_delete_char_0-OIUCpt.el 906173 ? Ssl 0:00 /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-64656c6574652d63686172_delete_char_0-vdo6Ms.el 906176 ? Ssl 0:00 /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-64656c6574652d63686172_delete_char_0-FlArQM.el 906177 ? Ssl 0:00 /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-64656c6574652d63686172_delete_char_0-gvBALD.el 906180 ? Ssl 0:00 /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-64656c6574652d63686172_delete_char_0-jKWQKF.el 906181 ? Ssl 0:00 /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-64656c6574652d63686172_delete_char_0-6jpknA.el 906184 ? Ssl 0:00 /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-64656c6574652d63686172_delete_char_0-rjrQSW.el 906185 ? Ssl 0:00 /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-64656c6574652d63686172_delete_char_0-sdGtrI.el 906188 ? Ssl 0:00 /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-64656c6574652d63686172_delete_char_0-0I2cpt.el 906189 ? Ssl 0:00 /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-64656c6574652d63686172_delete_char_0-Wks6rU.el 906192 ? Rsl 0:00 /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-64656c6574652d63686172_delete_char_0-nn0nkj.el 906193 ? Rsl 0:00 /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-64656c6574652d63686172_delete_char_0-iXBidj.el 906196 pts/11 R+ 0:00 ps -ax --- Version-Release number of selected component (if applicable): emacs-1:28.1-2.fc36.x86_64 emacs-ess-18.10.2-6.fc36.noarch emacs-common-ess-18.10.2-6.fc36.noarch How reproducible: Always Steps to Reproduce: 1. upgrade to emacs 28, have emacs-ess 2. launch emacs 3. Actual results: CPU consumption shoots up, multiple emacs processes spawn, and multiple files /tmp/emacs-int-comp-subr--trampoline-64656c6574652d63686172_delete_char_0-*.el are created, plus one /tmp/emacs-async-comp-ess-custom-*.el . emacs not useable and get stuck loading /usr/share/emacs/site-lisp/site-start.d/ess-init.el Expected results: start up should finish and one should be able to use emacs normally. Additional info: "dnf downgrade emacs" offers 1:27.2-9.fc35 (not fc36), and after downgrading, it works.
Since downgrading emacs work around this problem, I would think it is a compatibility problem of ess with emacs. FWIW, after doing it twice (and did "killall emacs" in another window both times): $ ls -l /tmp/emacs* | wc -l 258 It leaves behind a lot of files of the form: /tmp/emacs-int-comp-subr*.el
I can confirm that this happens on Fedora 36, with emacs-28.1-2.fc36.x86_64 and emacs-ess-18.10.2-6.fc36 Often times the spawned emacs processes consume enough memory to invoke the OOM killer which will start killing emacs and other processes as well. Even if the system in question has enough RAM to keep spawning emacs, emacs itself stays unresponsive and cannot be used. Ctrl-g can get you back to using emacs but initialization hasn't completed so it's not really usable.
The current stable version in Fedora is from 2018... Could you please try with snapshot in Melpa (20220727.1131) say?
BTW the upstream ticket for this is https://github.com/emacs-ess/ESS/issues/1207
It may also be good to try to add the native elisp compilation into the emacs-ess package.
(In reply to Jens Petersen from comment #3) > Could you please try with snapshot in Melpa (20220727.1131) say? This appears to install/compile for me from MELPA at least (I am not an ess user). See https://melpa.org/#/getting-started if you are not familiar with Emacs' package management.
Tried ESS current git head, same problem. Did a bit of digging, more details at https://github.com/emacs-ess/ESS/issues/1222 , long story short, the resource exhaustion seems to be coming from emacs 28's native compilation capability, which is a new feature in emacs 28 which fedora switched on by default. I believe the resource exhaustion comes from emacs trying do do "(comp--native-compile "/usr/share/emacs/site-lisp/ess/lisp/ess-custom.el" t)".
This is indeed unfortunate. I wonder if this is something that is/has been addressed in upstream emacs yet. It might be worth trying it on a emacs 29 snapshot.
Can you share the specs of your Fedora instance?
Maybe it is worth trying to set native-comp-async-jobs-number (by default comp uses half the cpus, which could be too much for some larger elisp packages perhaps?).
The emacs-vm package worked around this by disabling native-comp for itself in it vm-init.el file: + ;; For some reason, native compilation breaks VM. As a workaround until the + ;; problem is understood and fixed, disable native compilation of all VM + ;; lisp files. + (eval-after-load "comp" + '(if (boundp 'native-comp-deferred-compilation-deny-list) + (add-to-list 'native-comp-deferred-compilation-deny-list "/vm.*\.el"))) https://src.fedoraproject.org/rpms/emacs-vm/c/909b0bc357976252c51502bf17ed1efc6aeb7b97?branch=rawhide
(In reply to Jens Petersen from comment #11) > The emacs-vm package worked around this by disabling native-comp for itself > in it vm-init.el file: > > + ;; For some reason, native compilation breaks VM. As a workaround until the > + ;; problem is understood and fixed, disable native compilation of all VM > + ;; lisp files. > + (eval-after-load "comp" > + '(if (boundp 'native-comp-deferred-compilation-deny-list) > + (add-to-list 'native-comp-deferred-compilation-deny-list > "/vm.*\.el"))) > > https://src.fedoraproject.org/rpms/emacs-vm/c/ > 909b0bc357976252c51502bf17ed1efc6aeb7b97?branch=rawhide How does this get included to the emacs-ess SPEC file, if it indeed can temporarily provide a workaround?
Well perhaps someone can open a PR with a fix? I see you are following https://github.com/emacs-ess/ESS/issues/1222
Perhaps José would welcome help with maintaining this package too?
(In reply to Jens Petersen from comment #13) > Well perhaps someone can open a PR with a fix? > > I see you are following https://github.com/emacs-ess/ESS/issues/1222 Yes, indeed, I filed the original cases both on github as well as here. I could not figure out the syntax for emacs-common-ess following emacs-vm. Perhaps someone can help.
The emacs-vm thing is a red-herring. Tried that and it does not work. I think I understand the issue now, and it is generic to emacs, and should be reported up - probably have an existing bug entry in emacs's bug tracker already. Somebody want to look there and file? Anyway, here is my latest post to https://github.com/emacs-ess/ESS/issues/1222#issuecomment-1356895711 , verbatim copied here: <quote> Hurray, I think I understand the bug now, and it is generic to emacs. I have a very simple work-around. The workaround is this: When you launch emacs, and it starts to eat resources and spawn a lot of process of the form: /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-64656c6574652d63686172_delete_char_0-QeNLBe.el Do a "killall emacs" to kill them all. You should have lots of "emacs-int-comp-subr--trampoline*.el" left overs in /tmp. Pick one, run this: /usr/bin/emacs -Q --batch -l /tmp/one-of-those-files Note the -Q there, that's important!!! That's it. Now you launch emacs, it should smoothly native-compile ess (i.e. it would spawn one or two new processes for a while, until it has done about 50 of them, quite gradually). I think it is some kind of race condition: to do any native compilations at all, a natively compiled trampolline must first be built; Without the "-Q", when emacs tries to build the trampoline, it loads ESS before the build, and thus the probem escalates. I found this out by scattering a lot of "no-native-compile" into ess's el files. That slows down self-multiplying native compilation of ESS itself enough, that once in a while the trampoline gets built and one of my accounts works afterwards. Deleting the native cache gets me back to the old situation, some accounts (I was trying things out with both root and user) still have a copy of ~/.emacs.d/eln-cache/28.1-b1f2d84a/subr--trampoline-64656c6574652d63686172_delete_char_0.eln, copying it over makes emacs works with another account again. Experimented with a "zero-sized" file for that, it stopped native compilation (I don't have R installed, so don't know if it works that way or not) all together. Then figured out how to make it by hand with -Q. </quote>
Note in my "ps -ax" above, I have exactly one of: /usr/bin/emacs --batch -l /tmp/emacs-async-comp-ess-custom-cyjHX9.el but multiple of: /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-64656c6574652d63686172_delete_char_0-5DY1M9.el You want to native-compile with "-Q" one of the latter groups. It doesn't matter which, you just pick one of "/tmp/emacs-int-comp-sub--trampoline..." and run the same command by hand with "-Q" added.
(In reply to Hin-Tak Leung from comment #16) > The emacs-vm thing is a red-herring. Tried that and it does not work. I > think I understand the issue now, and it is generic to emacs, and should be > reported up - probably have an existing bug entry in emacs's bug tracker > already. Somebody want to look there and file? Anyway, here is my latest > post to https://github.com/emacs-ess/ESS/issues/1222#issuecomment-1356895711 > , verbatim copied here: > > <quote> > Hurray, I think I understand the bug now, and it is generic to emacs. I have > a very simple work-around. The workaround is this: > > When you launch emacs, and it starts to eat resources and spawn a lot of > process of the form: > > /usr/bin/emacs --batch -l > /tmp/emacs-int-comp-subr--trampoline-64656c6574652d63686172_delete_char_0- > QeNLBe.el > > > Do a "killall emacs" to kill them all. You should have lots of > "emacs-int-comp-subr--trampoline*.el" left overs in /tmp. Pick one, run this: > > /usr/bin/emacs -Q --batch -l /tmp/one-of-those-files > > Note the -Q there, that's important!!! That's it. Now you launch emacs, it > should smoothly native-compile ess (i.e. it would spawn one or two new > processes for a while, until it has done about 50 of them, quite gradually). > > I think it is some kind of race condition: to do any native compilations at > all, a natively compiled trampolline must first be built; Without the "-Q", > when emacs tries to build the trampoline, it loads ESS before the build, and > thus the probem escalates. > > I found this out by scattering a lot of "no-native-compile" into ess's el > files. That slows down self-multiplying native compilation of ESS itself > enough, that once in a while the trampoline gets built and one of my > accounts works afterwards. Deleting the native cache gets me back to the old > situation, some accounts (I was trying things out with both root and user) > still have a copy of > ~/.emacs.d/eln-cache/28.1-b1f2d84a/subr--trampoline- > 64656c6574652d63686172_delete_char_0.eln, copying it over makes emacs works > with another account again. Experimented with a "zero-sized" file for that, > it stopped native compilation (I don't have R installed, so don't know if it > works that way or not) all together. Then figured out how to make it by hand > with -Q. > </quote> Thanks, is the race condition owing to emacs or emacs-ess upstream? Perhaps they would be helped by submitting a bug report.
I think it is generic to emacs upstream so should be reported to savannah. I have reported issues to upstream emacs before (and still have an open issue - I promised to give them an enhancement doc diff a year or so ago, meant to do it last Christmas...) . The issue seems pretty clear to me: the trampoline seems to be some kind of precursor/dependency to any native compilation at all, so the 50+ ess *.el files triggers about 50 copies of it being built, and overwriting each other, and each of those 50+ launches, without "-Q", loads ess too, which becomes 50×50, then 50x50x50, etc. To arrive at this conclusion, I added a whole piles of no-native-compile to them as file-local variables, and slow it down to 6, 6x6, 6x6x6. Once in a while it gets done and stops the self-multiplying. I think this issue basically affects any large-enough (as in multiple *.el) packages.
Filed upstream as: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=60208 "28.1; Resource exhaustion with emacs 28's native compilation; need "-Q" for trampoline"
Just saving people looking at the upstream gnu.org exchange - turn out the fact that Fedora has a "/usr/share/emacs/site-lisp/site-start.d/ess-init.el" , which contains the single line, "(require 'ess-site)", is important. Emacs doesn't do recursive loading via user config (~/.emacs) when native-compiling. But site-wide auto-loading via /usr/share/emacs/site-lisp/site-start.d/ess-init.el is not currently catered for. At the moment the fix is looking to be a new emacs release .
Fix pushed to emacs 29 branch: https://git.savannah.gnu.org/cgit/emacs.git/commit/?h=emacs-29 Somebody at redhat wants to backport to emacs 28?
Perhaps, should file a bug under emacs component with the patch from https://git.savannah.gnu.org/cgit/emacs.git/commit/?h=emacs-29?
Sorry, better url for the fix: https://git.savannah.gnu.org/cgit/emacs.git/commit/?h=emacs-29&id=e59216d3be86918b995bd63273c851ebc6176a83 It seems simple enough to backport to 28.1, before if/when this might be included in 28.2.
Copied bug to component emacs as https://bugzilla.redhat.com/show_bug.cgi?id=2155824
New fc36 emacs rpm's available: https://bugzilla.redhat.com/show_bug.cgi?id=2155824#c3 the fc37 build somehow failed, so I have the fc36 rpm's replacing those shipped with fc37. (dnf upgrade works because 3.1.fc36 is still higher than 3.fc37). They work and seem to fix the bug!
Thank you Hin-Tak Leung! Yes I did some x86_64 scratch builds with a backport of the upstream fix to emacs-28: F36: https://koji.fedoraproject.org/koji/taskinfo?taskID=95626001 F37: https://koji.fedoraproject.org/koji/taskinfo?taskID=95626270 (this one succeeded) Rawhide: https://koji.fedoraproject.org/koji/taskinfo?taskID=95622287 (note this one is emacs-28.2) You should be able to install them with `koji-tool install <taskid>` or of course you can download the rpms manually (or with `koji download-task --arch=x86_64 <taskid>`) and install by hand, etc. If more people could test them that would be helpful: more details in the above emacs bug that Hin-Tak opened. I plan to open a PR today with this fix, so that we can get it into Fedora soon hopefully.
Tested the f37 ones now too. They work correctly as expected. To test, download the 3 emacs, emacs-common, emacs-filesystem, rpm's for your system (or sufficient to replaces your current emacs - I needed those 3, others may need one or two more, or the emacs-nox rpm, for example). Clean out ~/.emacs.d/eln-cache/28.1-b1f2d84a/ , then launch emacs. It should finish loading ess-init.el very soon, but cpu usage would continue to stay at about 50% while repopulating ~/.emacs.d/eln-cache/28.1-b1f2d84a/ gradually; one or two emacs sub-process would appear from time to time in the background, but nothing excessive like 10 or 100's. There are 3 emacs buffers, Async-native-compile-log, Native-compile-Log, and Warning-Log, gradually filling up with log messages. The warning-log can be switched off by an offered option at the end of the buffer.
For your information even if not strictly related to this issue: I tried the F37 packages Jens built and used it with emacs-vm. I does seem to solve the actual error that occurred when using emacs-vm. (It works the first time it is run. But the second time, when the eln files already exist, one gets an "incorrect arguments" error. I'm not sure how it is related to these fixes, but they do seem to help.) A separate problem with natively compiling emacs-vm is it spews loads of warnings. That is (most likely) related to emacs-vm getting very little attention upstreams and it using obsolete functionality. I hope to have a chance to get involved there myself, but I don't know when that will happen. In the mean time I'll keep the disabling of native compilation in emacs-vm, it does give a somewhat better end user experience. Otherwise, emacs-28.1-3.1.fc37 seems to work fine for me, so far at least.
(In reply to Göran Uddeborg from comment #29) > For your information even if not strictly related to this issue: I tried the > F37 packages Jens built and used it with emacs-vm. ... About emacs-vm . Instead of switching off native compilation itself, how about setting the two variables to switching off compilation warnings and logging? I agree they are annoying, so for naive users probably should off switch off. Emacs-ess has a similar problem - the redhat shipped version (quite old) generates a lot of warnings. Switching to an upstream snapshot is a lot quieter. But it is mostly about upstream making a release and/or packager shipping a snapshot; separate issue from the resource exhaustion. Does emacs-vm also suffer from resource exhaustion? I don't think it builds any trampolines (or the current rpm does not) so probably separate.
I am on F36, actually pending the fix of this bug. How can i check it out for F36?
(In reply to Ranjan Maitra from comment #31) > I am on F36, actually pending the fix of this bug. How can i check it out > for F36? Just download the 3 rpms - most people need emacs, emacs-common, emacs-filesystem at least (or more - you may need one or two more, dnf will tell you if you do) from the f36 build link above. Run "dnf upgrade <download loadedfiles>" as root. That's it. The download link is in comment 27, and a bit more details in comment 28 of what to expect: https://bugzilla.redhat.com/show_bug.cgi?id=2109745#c28
(In reply to Hin-Tak Leung from comment #30) > About emacs-vm . Instead of switching off native compilation itself, how > about setting the two variables to switching off compilation warnings and > logging? Is it possible to suppress compilation warnings for particular files only? I'm aware of "warning-suppress-types" but that would disable *all* such warnings. It would not seem appropriate to me to do that just because of VM. But if it can be done for only vm-* files it would be another matter. In any case, it is not an option with the current emacs in Fedora. It is not only about the warnings, VM doesn't work when natively compiled. On the initial load, when everything gets compiled, it works even if it sees a lot of warnings. But on the second invocation of emacs, when there already are natively compiled files, it stops with an error message "byte-code: Wrong number of arguments: #<subr load>, 0" when loading VM. I guessed it was a consequence of some of the errors reported. But that latter problem actually goes away with 28.1-3.1.fc37 while the warnings of course remain, so maybe the two problems are unrelated. If so, one could consider something less intrusive for VM once a new patched emacs is generally available in the repositories. > Does emacs-vm also suffer from resource exhaustion? It does not. I see the compilation process run briefly, but it goes away rather quickly.
(In reply to Hin-Tak Leung from comment #32) > (In reply to Ranjan Maitra from comment #31) > > I am on F36, actually pending the fix of this bug. How can i check it out > > for F36? > > Just download the 3 rpms - most people need emacs, emacs-common, > emacs-filesystem at least (or more - you may need one or two more, dnf will > tell you if you do) from the f36 build link above. Run "dnf upgrade > <download loadedfiles>" as root. That's it. The download link is in comment > 27, and a bit more details in comment 28 of what to expect: > > https://bugzilla.redhat.com/show_bug.cgi?id=2109745#c28 Thanks, am trying these out now, but will these eventually show up on the official repos?
(In reply to Ranjan Maitra from comment #34) > but will these eventually show up on the official repos? Yes, you may want to track bug 2155824. Actually I wanted to push it before 28.2, but currently waiting on the de facto maintainer...
(In reply to Jens Petersen from comment #27) > Thank you Hin-Tak Leung! > > Yes I did some x86_64 scratch builds with a backport of the upstream fix to > emacs-28: > > F36: https://koji.fedoraproject.org/koji/taskinfo?taskID=95626001 > F37: https://koji.fedoraproject.org/koji/taskinfo?taskID=95626270 (this one > succeeded) > Rawhide: https://koji.fedoraproject.org/koji/taskinfo?taskID=95622287 (note > this one is emacs-28.2) > > You should be able to install them with `koji-tool install <taskid>` or of > course you can download the rpms manually (or with `koji download-task > --arch=x86_64 <taskid>`) and install by hand, etc. > > If more people could test them that would be helpful: more details in the > above emacs bug that Hin-Tak opened. > > I plan to open a PR today with this fix, so that we can get it into Fedora > soon hopefully. THis works for me. How do I switch off the warning messages?
I also get the following regardless of which file I open with emacs (even one not involving ESS). Warning (comp): /usr/share/emacs/site-lisp/ess/ess-r-package.el: Error: Wrong number of arguments (3 . 4) Disable showing Disable logging
If you click "Options", "Customize emacs" ... you get to a submenu. Either 'specific group' (type 'warning') or 'specific option' (for the full name below) would work... These are the two options auto-created when I clicked 'suppress warning', 'suppress log' in one of the earlier sessions at the end of the buffer offered, inserted into my .emacs by emacs itself. Similar effect can be achieved by inputting 'comp' in the 'specific option' with 'warning suppress log types', etc. 'comp' is the emacs lisp module for doing native compilation. (custom-set-variables ;; custom-set-variables was added by Custom. ;; If you edit it by hand, you could mess it up, so be careful. ;; Your init file should contain only one such instance. ;; If there is more than one, they won't work right. '(warning-suppress-log-types '((comp))) '(warning-suppress-types '((comp)))) I still get one line in one of the emacs buffers. It is like the message buffer, you don't need to read it if you don't want to. If you do it via 'customize emacs' or those toggles at the end of the buffers, you get to undo them via 'Customize emacs' -> 'Saved options' too.
FEDORA-2022-e37f239f2e has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-e37f239f2e
FEDORA-2022-d69c7f95a4 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-d69c7f95a4
FEDORA-2022-d69c7f95a4 has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-d69c7f95a4` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-d69c7f95a4 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-e37f239f2e has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-e37f239f2e` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-e37f239f2e See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-d69c7f95a4 has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2022-e37f239f2e has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.