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 executable

Miquel Sabate Sola (mssola) - over 3 years ago

Same 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.

Peter Münster (pmrb) - over 3 years ago

Should be fixed now: https://bugzilla.opensuse.org/show_bug.cgi?id=1175372 Peter

---

1st last (mark314) - over 3 years ago

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/3768

Is 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.

Björn Bidar (Thaodan) - 7 months ago

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

---

Dr. Werner Fink (WernerFink) - 7 months ago

maintainer

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

Dr. Werner Fink (WernerFink) - 7 months ago

maintainer

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.

---

Björn Bidar (Thaodan) - 7 months ago

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?

---

Björn Bidar (Thaodan) - 7 months ago

My simpler pdmp patch is here: https://github.com/Thaodan/emacs/commit/54823555425ffabe31b42672b1894d0e3ff1b018

---

Dr. Werner Fink (WernerFink) - 7 months ago

maintainer

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.

---

Dr. Werner Fink (WernerFink) - 7 months ago

maintainer

The eln files had to be saved away just like the binaries them selfs ... could be done by make install-eln with a specific DESTDIR

---

Björn Bidar (Thaodan) - 7 months ago

I 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 out

Björn Bidar (Thaodan) - 7 months ago

It 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.

---

Dr. Werner Fink (WernerFink) - 7 months ago

maintainer

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 :)

---

Björn Bidar (Thaodan) - 7 months ago

Pgtk uses GSettings instead odf XRessources.

---

Dr. Werner Fink (WernerFink) - 7 months ago

maintainer

Hmmm ... is there a tool to get the old X server resource database into the GSettings ...

xrdb -query | wc -l
371

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.

Dr. Werner Fink (WernerFink) - 7 months ago

maintainer

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

Dr. Werner Fink (WernerFink) - 7 months ago

maintainer

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.

Dr. Werner Fink (WernerFink) - 7 months ago

maintainer

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

---

Björn Bidar (Thaodan) - 7 months ago

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.

---

Dr. Werner Fink (WernerFink) - 7 months ago

maintainer

Every message seen by normal users causes bugzilla entries ... for spacemacs ... are you using wayland? Means emacs-wayland here

---

Björn Bidar (Thaodan) - 6 months ago

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?

Dr. Werner Fink (WernerFink) - 3 months ago

maintainer

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.

dev (dev_bayesians) - about 1 month ago

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?

Dr. Werner Fink (WernerFink) - 17 days ago

maintainer

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.

---

Björn Bidar (Thaodan) - 15 days ago

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.

---

Dr. Werner Fink (WernerFink) - 13 days ago

maintainer

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 ;)