Gnu Emacs
"Eight Megs And Constantly Swapping"
- Devel package for openSUSE:Factory
-
11
derived packages
- Links to openSUSE:Factory / emacs
- Download package
-
Checkout Package
osc -A https://api.opensuse.org checkout editors/emacs && cd $_ - Create Badge
Refresh
Refresh
Source Files (show merged sources derived from linked package)
| Filename | Size | Changed |
|---|---|---|
| _link | 0000000124 124 Bytes | |
| app-defaults.Emacs | 0000008459 8.26 KB | |
| check-build.sh | 0000000592 592 Bytes | |
| dot.gnu-emacs | 0000019025 18.6 KB | |
| emacs-24.1-ps-mule.patch | 0000001729 1.69 KB | |
| emacs-24.3-asian-print.patch | 0000000463 463 Bytes | |
| emacs-24.3-iconic.patch | 0000000563 563 Bytes | |
| emacs-24.3-x11r7.patch | 0000001130 1.1 KB | |
| emacs-24.4-flyspell.patch | 0000001830 1.79 KB | |
| emacs-24.4-glibc.patch | 0000000553 553 Bytes | |
| emacs-24.4-nonvoid.patch | 0000000482 482 Bytes | |
| emacs-24.4-ps-bdf.patch | 0000001529 1.49 KB | |
| emacs-25.1-custom-fonts.patch | 0000002357 2.3 KB | |
| emacs-25.2-ImageMagick7.patch | 0000001922 1.88 KB | |
| emacs-26.1-xft4x11.patch | 0000001043 1.02 KB | |
| emacs-27.1-Xauthority4server.patch | 0000005546 5.42 KB | |
| emacs-27.1-pdftex.patch | 0000003481 3.4 KB | |
| emacs-29.1.dif | 0000031636 30.9 KB | |
| emacs-29.4-pdf.tar.xz | 0002032912 1.94 MB | |
| emacs-29.4.tar.xz | 0052210344 49.8 MB | |
| emacs-29.4.tar.xz.sig | 0000000520 520 Bytes | |
| emacs-CVE-2024-53920.patch | 0000001987 1.94 KB | |
| emacs-gcc14.patch | 0000001345 1.31 KB | |
| emacs-rpmlintrc | 0000000685 685 Bytes | |
| emacs.changes | 0000131165 128 KB | |
| emacs.keyring | 0000010680 10.4 KB | |
| emacs.sh | 0000004180 4.08 KB | |
| emacs.spec | 0000276362 270 KB | |
| emacs.test | 0000000490 490 Bytes | |
| macros.emacs | 0000000211 211 Bytes | |
| pdump.patch | 0000000999 999 Bytes | |
| site-lisp.tar.bz2 | 0000052003 50.8 KB |
Comments 52
With 27.1 I get this message when I try to start emacs
desired fingerprint: 064a75c503ad2029dae4f4f0f451795521ec88ed472d4af90d830dca9f0a8982 found fingerprint: d175eee5d621820266e4493384b96880b9f3a0bbb75ac7d1f90a38f25cab8590 emacs: could not load dump file "/usr/lib/emacs/27.1/x86_64-suse-linux/emacs.pdmp": not built for this Emacs executableSame here.
With emacs 27.1 on Leap15.1, fonts only render & display properly if emacs is invoked with "--no-x-resources". This hold true even when contrasting a bare-bones-invocation with "-q" against "-q --no-x-resources": with "-q", fonts render pixely. They render smooth with "-q --no-x-resources". The Leap 15.1 install has no ".Xdefaults" in the user's home dir. This issue has not existed with 26.3.
Should be fixed now: https://bugzilla.opensuse.org/show_bug.cgi?id=1175372 Peter
Yep. Confirming, that with emacs-27.1-lp151.335.1.x86_64 and on Leap 15.1, fonts render & display properly again without the --no-x-resources switch. Thx guys.
I confirm this behavior with
doom-emacs. I filed a bug about it https://github.com/hlissner/doom-emacs/issues/3768Is this going to be built with nativecomp? It's a very interesting feature to have.
Emacs 29.1 is released with a separate wayland module/feature 👀
Please update! I can do it tonight if you aren't free ❤️
Is it possible to turn on pgtk option builds?This is a very useful feature for Wayland users.
Without disabling the warnings in PGTK that would break the gtk build when using X11. sed -i 's, pgtk_display_x_warning,// pgtk_display_x_warning,' src/pgtkterm.c
https://gist.github.com/probonopd/9feb7c20257af5dd915e3a9f2d1f2277
Emacs developers say that sharing the native-lisp binaries between builds that use different configurations e.g. the X11 and GTK build is not advised.
Doing so broke a few months ago in Emacs devel after gnulib was updated. I'm not sure if the gnulib update is relevant but that is the first commit I think which broke packaging on -eln package for all builds broke.
https://mail.gnu.org/archive/html/emacs-devel/2023-08/msg00458.html
Only the emacs build for GTK supports Native Lisp as otherwise the X11 as well as the noX build would triple the numbers of .eln files. And AFAICS the advantage of using Native Lisp isn't that much, maybe as I'm using user systemd serivce which start emacs as daemon.
Turns out I had issues because after building each build distclean cleaned the eln files. This was changed quite recently, before it didn't delete them. I was under the thinking that we could have kept one set of eln files - one package, but that isn't possible. Of course it tripples the amount of files but I think it is useful potentially for all builds - daemon or not.
I need to move them manually before running distclean.
I have a simpler patch for the override the pdmp base per build, do you want to take that?
Also I track some patches of your in git. Are you open to do also do the same for this package? The advantage is that the patches can be shared between my package and yours.
Why is the emacs-27.1-pdftex.patch needed to build the docs for OpenSuSE?
My simpler pdmp patch is here: https://github.com/Thaodan/emacs/commit/54823555425ffabe31b42672b1894d0e3ff1b018
The emacs-27.1-pdftex.patch exists only to build all refcards with the fonts provided by TeXLive
For your pdmp patch ... do you have tested it with all emacs binaries (emacs-nox, emacs-x11, and emacs-gtk) and the wrapper script /usr/bin/emacs .. simply to avoid the desaster reported e.g in bug boo#1214008 (this was a brown paper back indeed :)
Beside this I'm consider to provide also a emacs-pgtk in an own package emacs-wayland for the poor wayland users.
The eln files had to be saved away just like the binaries them selfs ... could be done by
make install-elnwith a specific DESTDIRI was thinking of doing so but preventing distclean to cleanup eln files was easier: make distclean HAVE_NATIVE_COMP=no
I noticed that eln files are installed into /usr/lib because, libdir isn't passed to configure. I assume it is because the %configure isn't used.
Latest version now has wayland gtk based binary which is used only for
XDG_SESSION_TYPE=wayland... also all binaries have their own eln native files as I'm now using Björn's pdmp patch ... please test outIt is also possible to use pgtk on X11 if the pgtk_display_x11_warning is removed:
sed -i 's, pgtk_display_x_warning,// pgtk_display_x_warning,' src/pgtkterm.c
PGTK works fine on X11 and has less issues with for example high-dpi screens and lets you use GTK input methods.
In my experience the pgtk seems to ingore my Xresource/Xdefaults entries for emacs ... that is pgtk is white whereas the pure X11 gtk shows my favourite colouring :)
Pgtk uses GSettings instead odf XRessources.
Hmmm ... is there a tool to get the old X server resource database into the GSettings ...
I noticed that site-start.el contains various variables and references to out of date informations such as gnus-localdomain. Check Emacs's NEWS.29 for more.
I also wonder if these files should be maintained outside of the tar archive e.g. in a patch.
The tar ball site-lisp.tar.bz2 is a very old source which are the leftovers of more than 25 years of using GNU Emacs which I had collected at university and maintained over the years. If you have suggestions for adding/removing parts you're welcome
Now message-user-fqdn is used
Does Emacs support atspi-2 directly? I greped the Emacs sources, I couldn't find any reference. I think it's more of a GTK feature.
Yep .. .nevertheless for gtk and wayland I'd like to avoid warnings ... btw ... see bug boo#1216040 ... after the change from lib to lib64 spacemacs runs into problems
Which warnings? I see atspi-2 more as a recommend. Since Emacs use atspi-2 during build it should more be a recommend.
I checked the bug, after changing my own emacs package to have the precompiled in lib64 I didn't had any issue. I tested spacemacs no issue there either. I suspect that he had to delete his eln-cache after the change.
Every message seen by normal users causes bugzilla entries ... for spacemacs ... are you using wayland? Means emacs-wayland here
Yes I was using Emacs with the PGTK backend on Wayland or X11 no issue.
Emacs 29.2 was released on 2024-01-18. When is it expected to be available?
Should be done now
I noticed that the Emacs packaging macros are not picked up on Leap, do you know why? The macros look line to me.
Would it make sense to add Prefer: emacs-nox for the obs so that Emacs package can correctly depend on emacs-devel without depending on emacs-nox directly?
Emacs 29.3 which addresses some security vulnerabilities has been released. Hoping to see it in TW soon.
Thank you for the prompt release.
Line 610 of emacs.spec: ln -sf ../parking./usr/lib64/emacs/29.1/native-lisp/ .
Should be: ln -sf ../parking./usr/lib64/emacs/29.3/native-lisp/ .
Or better yet: ln -sf ../parking./usr/lib64/emacs/%{version}/native-lisp/ .
Why is Emacs built with ffno-optimize-sibling-calls?
In past I had run onto problems with some gcc versions during byte-compiling some lisp files and as I always recompile all lisp files as a test this option had avoided this crash. This is also mention in emacs-<version>/etc/PROBLEMS where I found this hint. I do not care if this is gcc or emacs code, it has to byte-compiling its lisp files from scratch.
Oh I wasn't aware of the issue. Other distributions don't enable this flag and reading the document makes it look like it should only affect very old GCC's.
No idea if other distribution re-byte-compile all lisp files for a check ... also if I would have a check which gcc version does throw such error before byte-compile lisp file would help. The question rises if the disabled optimize-sibling-calls hurts the real life performance ... sometimes less is more ;)
Should checks be enabled for the editor project but disabled in Factory? Fedora went ahead and also run tests in their CI.
What checks do you mean ...
Staging Projects for editorsor something differentI mean the unit tests in make check. We could enable them there to catch potential errors before updating the package in Factory.
@WernerFink why was configure flag
--with-emojinot set ?where did you find such an option?
Good question:
yes, my fault. there is no such flag
Hey,
Are you considering to install all Emacs packages provided by the repositories using package.el? The ELPA repositories only work only when using package.el from what I know as opposed to site-lisp which works with without package.el.
Since I have been building Emacs 30 for quite a while for openSUSE I have rebased most of the patches. Right now I have rebased them against Emacs 30 and 31. Some of the patches I didn't add so far such as the XAuth patch.
Could you when you cherry-pick patches take the actual patch file from git instead of a diff? This does make rebasing match easier.
My rebased patches are here: https://github.com/Thaodan/emacs/commits/thaodan/emacs-30/opensuse_patches