https://fedoraproject.org/wiki/Changes/Emacs_28
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.
== Summary ==
Update GNU Emacs to 28.1 release. This release includes a wide variety of new features, including native compilation of Lisp files.
== Owner ==
* Name: [[User:Bhavin192| Bhavin Gandhi]] * Email: bhavin192@fedoraproject.org
== Detailed Description ==
The Emacs package will be updated to 28.1 release of GNU Emacs. This will have native compilation feature enabled, and will package additional natively compiled Lisp files.
== Benefit to Fedora ==
This major version of Emacs has bugfixes and new features which also improve the overall speed of Emacs.
== Scope ==
* Proposal owners: Upgrade the Emacs package to 28.1 * Other developers: N/A * Release engineering: N/A (not needed for this Change) * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: N/A
== Upgrade/compatibility impact ==
Users might see some warnings while their installed Emacs packages get natively compiled after first launch post the upgrade. These warnings won't break any functionality, though the users are encouraged to update their Emacs packages.
== How To Test ==
# Run dnf update emacs # Open Emacs and check if inbuilt functionalities and packages work as indented.
== User Experience ==
https://www.gnu.org/software/emacs/#Releases
* Lisp files are natively compiled, this results in speed improvements for most of the functionalities * Much improved display of Emoji and Emoji sequences * New system for documenting groups of functions
== Dependencies == N/A
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change), No
== Documentation == * https://www.gnu.org/software/emacs/news/NEWS.28.1 * https://src.fedoraproject.org/rpms/emacs/pull-request/12
== Release Notes == The upstream release notes are available at https://www.gnu.org/software/emacs/news/NEWS.28.1
These can also be accessed from within Emacs by doing `C-h n`.
Dear Bhavin,
A big "yay!" for packaging 28.1; I've been running my own emacs.spec modifications to play around with this, for one reason, and one reason alone:
PGTK support. Without it, emacs is virtually unusable on Wayland on hidpi screens with the compositors I've used, as xwayland simply scales pixel-images.
Since the pgtk toolkit supports both X and wayland under the hood, I'd very much propose that we do not only package an emacs-pgtk binary, but also, that it becomes what you get by default (i.e. when you install and run `emacs`).
Felt too big a change to propose for me, a GNU emacs newbie, but I was surprised to see a change proposal for a normal software version bump of emacs (it's not like say GNU Radio makes a change proposal every time they bump version), but then not include that, which feels a bit like a missed chance to round-off the wayland experience of Fedora!
Best regards, Marcus
On 18.07.22 19:29, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/Emacs_28
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.
== Summary ==
Update GNU Emacs to 28.1 release. This release includes a wide variety of new features, including native compilation of Lisp files.
== Owner ==
- Name: [[User:Bhavin192| Bhavin Gandhi]]
- Email: bhavin192@fedoraproject.org
== Detailed Description ==
The Emacs package will be updated to 28.1 release of GNU Emacs. This will have native compilation feature enabled, and will package additional natively compiled Lisp files.
== Benefit to Fedora ==
This major version of Emacs has bugfixes and new features which also improve the overall speed of Emacs.
== Scope ==
- Proposal owners: Upgrade the Emacs package to 28.1
- Other developers: N/A
- Release engineering: N/A (not needed for this Change)
- Policies and guidelines: N/A (not needed for this Change)
- Trademark approval: N/A (not needed for this Change)
- Alignment with Objectives: N/A
== Upgrade/compatibility impact ==
Users might see some warnings while their installed Emacs packages get natively compiled after first launch post the upgrade. These warnings won't break any functionality, though the users are encouraged to update their Emacs packages.
== How To Test ==
# Run dnf update emacs # Open Emacs and check if inbuilt functionalities and packages work as indented.
== User Experience ==
https://www.gnu.org/software/emacs/#Releases
- Lisp files are natively compiled, this results in speed improvements
for most of the functionalities
- Much improved display of Emoji and Emoji sequences
- New system for documenting groups of functions
== Dependencies == N/A
== Contingency Plan ==
- Contingency mechanism: (What to do? Who will do it?) N/A (not a
System Wide Change)
- Contingency deadline: N/A (not a System Wide Change)
- Blocks release? N/A (not a System Wide Change), No
== Documentation ==
- https://www.gnu.org/software/emacs/news/NEWS.28.1
- https://src.fedoraproject.org/rpms/emacs/pull-request/12
== Release Notes == The upstream release notes are available at https://www.gnu.org/software/emacs/news/NEWS.28.1
These can also be accessed from within Emacs by doing `C-h n`.
On Tue, Jul 19, 2022 at 5:14 AM Marcus Müller marcus@hostalia.de wrote:
Since the pgtk toolkit supports both X and wayland under the hood, I'd very much propose that we do not only package an emacs-pgtk binary, but also, that it becomes what you get by default (i.e. when you install and run `emacs`).
Good catch, but it looks to me like pgtk was deferred to Emacs 29! Seems it is not actually part of 28.
Jens
Oh! That comes as a surprise. Let me try a rebuild!
:( I was really looking forward to emacs-pgtk.
Best regards, Marcus
On 19.07.22 11:53, Jens-Ulrik Petersen wrote:
On Tue, Jul 19, 2022 at 5:14 AM Marcus Müller marcus@hostalia.de wrote:
Since the pgtk toolkit supports both X and wayland under the hood, I'd very much propose that we do not only package an emacs-pgtk binary, but also, that it becomes what you get by default (i.e. when you install and run `emacs`).Good catch, but it looks to me like pgtk was deferred to Emacs 29! Seems it is not actually part of 28.
Jens
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 7/20/22 14:57, Marcus Müller wrote:
Oh! That comes as a surprise. Let me try a rebuild!
:( I was really looking forward to emacs-pgtk.
Forgive my relative newbie-ness here, but this proposal is to upgrade Emacs to version 28 in F37. That seems fine.
This week my F36 system got upgraded to Emacs version 28, so it's already in F36. How is that possible?
On Wed, Jul 20, 2022 at 1:38 PM Kevin P. Fleming kpfleming@redhat.com wrote:
Forgive my relative newbie-ness here, but this proposal is to upgrade Emacs to version 28 in F37. That seems fine.
This week my F36 system got upgraded to Emacs version 28, so it's already in F36. How is that possible?
For even more fun, Emacs 28 broke at least two packages I maintain: bigloo and pvs-sbcl. I've already pushed a fix for bigloo, but the pvs-sbcl breakage has me pulling my hair out.
He Kevin,
oh, true, after all, dnf info --releasever=36 emacs agrees with you. Now, I'm kind of confused about the point of the change proposal?
emacs -nw -q --batch --eval '(message system-configuration-options)' 2>&1 | grep native compilaion
also tells me that the announced native compilation is also enabled, so maybe something slipped through a little early?
Cheers, Marcus
On 20.07.22 21:36, Kevin P. Fleming wrote:
On 7/20/22 14:57, Marcus Müller wrote:
Oh! That comes as a surprise. Let me try a rebuild!
:( I was really looking forward to emacs-pgtk.
Forgive my relative newbie-ness here, but this proposal is to upgrade Emacs to version 28 in F37. That seems fine.
This week my F36 system got upgraded to Emacs version 28, so it's already in F36. How is that possible?
Hi Kevin and all,
"Kevin P. Fleming" kpfleming@redhat.com writes:
On 7/20/22 14:57, Marcus Müller wrote:
Oh! That comes as a surprise. Let me try a rebuild!
:( I was really looking forward to emacs-pgtk.
Forgive my relative newbie-ness here, but this proposal is to upgrade Emacs to version 28 in F37. That seems fine.
This week my F36 system got upgraded to Emacs version 28, so it's already in F36. How is that possible?
Apologies, this is my fault. After the Emacs 28 PR got merged, I went ahead, built Emacs in Fedora 36 as well and submitted it as an update [1] (after one borked attempt before), which got quickly pushed to stable.
Sorry for breaking your packages Jerry. Maybe we should add some gating tests to prevent this kind of breakage in the future. Would you have some details what happened?
Sorry for this mess,
Dan
Footnotes: [1] https://bodhi.fedoraproject.org/updates/FEDORA-2022-d75f0c2a4a
On Wed, 20 Jul 2022 at 16:12, Dan Čermák dan.cermak@cgc-instruments.com wrote:
Hi Kevin and all,
"Kevin P. Fleming" kpfleming@redhat.com writes:
On 7/20/22 14:57, Marcus Müller wrote:
Oh! That comes as a surprise. Let me try a rebuild!
:( I was really looking forward to emacs-pgtk.
Forgive my relative newbie-ness here, but this proposal is to upgrade Emacs to version 28 in F37. That seems fine.
This week my F36 system got upgraded to Emacs version 28, so it's already in F36. How is that possible?
Apologies, this is my fault. After the Emacs 28 PR got merged, I went ahead, built Emacs in Fedora 36 as well and submitted it as an update [1] (after one borked attempt before), which got quickly pushed to stable.
Sorry for breaking your packages Jerry. Maybe we should add some gating tests to prevent this kind of breakage in the future. Would you have some details what happened?
I have seen a couple of reports about emacs not starting after update with the message:
``` Cannot open load file: No such file or directory, comp ```
Removing the users .emacs/.emacs.d does not change anything so I am guessing there is some other 'breakage'. What can be done to debug this?
On Thu, 21 Jul 2022 at 08:43, Stephen Smoogen ssmoogen@redhat.com wrote:
On Wed, 20 Jul 2022 at 16:12, Dan Čermák dan.cermak@cgc-instruments.com wrote:
Hi Kevin and all,
"Kevin P. Fleming" kpfleming@redhat.com writes:
On 7/20/22 14:57, Marcus Müller wrote:
Oh! That comes as a surprise. Let me try a rebuild!
:( I was really looking forward to emacs-pgtk.
Forgive my relative newbie-ness here, but this proposal is to upgrade Emacs to version 28 in F37. That seems fine.
This week my F36 system got upgraded to Emacs version 28, so it's already in F36. How is that possible?
Apologies, this is my fault. After the Emacs 28 PR got merged, I went ahead, built Emacs in Fedora 36 as well and submitted it as an update [1] (after one borked attempt before), which got quickly pushed to stable.
Sorry for breaking your packages Jerry. Maybe we should add some gating tests to prevent this kind of breakage in the future. Would you have some details what happened?
I have seen a couple of reports about emacs not starting after update with the message:
Cannot open load file: No such file or directory, compRemoving the users .emacs/.emacs.d does not change anything so I am guessing there is some other 'breakage'. What can be done to debug this?
User removed emacs related packages one by one and found that the problem was emacs-ddskk packages. I am guessing these may need some sort of work to continue working.
On Wed, Jul 20, 2022 at 2:10 PM Dan Čermák dan.cermak@cgc-instruments.com wrote:
Sorry for breaking your packages Jerry. Maybe we should add some gating tests to prevent this kind of breakage in the future. Would you have some details what happened?
Bigloo was easy to fix, so no problem there. The pvs-sbcl package uses some really old Emacs Lisp code. I'm working my way through the incompatibilities. There is quite a lot of deprecated usage. The error that actually makes things break is this:
Debugger entered--Lisp error: (wrong-type-argument sequencep #<subr lisp-mode>) append(#<subr lisp-mode> nil) ilisp-byte-code-to-list(#<subr lisp-mode>) ilisp-set-doc(lisp-mode "Major mode for interacting with an inferior Lisp p...") byte-code("\301\302\10"\210\301\303\10"\207" [ilisp-documentation ilisp-set-doc ilisp-mode lisp-mode] 3) load("ilisp-mod" nil nil) byte-code("\305\306!\210\307\310\311\10#\210\307\312\311\10#\210\307\313\311\10#\210\307\314\311\10#\210\307\315\311\10#\210\307\316\311\10#\210\307\317\311\10#\210\307\320\311\10..." [noninteractive ilisp-mode-map +ilisp-emacs-version-id+ ilisp-*enable-cl-easy-menu-p* ilisp-*enable-scheme-easy-menu-p* require cl load "ilcompat" nil "comint-ipc" "ilisp-def" "ilisp-sym" "ilisp-inp" "ilisp-ind" "ilisp-prc" "ilisp-val" "ilisp-out" "ilisp-mov" "ilisp-key" "ilisp-prn" "ilisp-low" "ilisp-doc" "ilisp-ext" "ilisp-mod" "ilisp-dia" "ilisp-cmt" "ilisp-rng" "ilisp-hnd" "ilisp-utl" "ilisp-cmp" "ilisp-kil" "ilisp-snd" "ilisp-xfr" "ilisp-hi" "ilisp-aut" "ilisp-cl" "ilisp-acl" "ilisp-cmu" "ilisp-sbcl" run-hooks ilisp-site-hook ilisp-load-hook ilisp-bindings (xemacs lucid-19 lucid-19-new fsf-20 fsf-21) "ilisp-mnb" (xemacs lucid-19 lucid-19-new fsf-20 fsf-21) "ilisp-cl-easy-menu" (xemacs lucid-19 lucid-19-new fsf-20 fsf-21) "ilisp-scheme-easy-menu" ...] 4) load("ilisp" nil nil) byte-code("\305\306!\210\307\310\311\10#\210\307\312\311\10#\210\307\313\311\10#\210\307\314\311\10#\210\307\315\311\10#\210\307\316\311\10#\210\307\317\311\10#\210\307\320\311\10..." [noninteractive emacs-major-version emacs-minor-version pvs-original-load-path load-path make-variable-buffer-local pvs-buffer-kind load "ilisp" nil "pvs-ilisp" "pvs-mode" "pvs-view" "pvs-file-list" "pvs-browser" "pvs-utils" "pvs-cmds" (error) "pvs-prelude-files-and-regions" "pvs-print" "pvs-proofstate" "pvs-prover" "pvs-abbreviations" boundp 20 19 29 "pvs-menu" "pvs-tcl" "pvs-prover-helps" "pvs-eval" "pvs-pvsio" "pvs-prover-manip" "manip-debug-utils" "prooflite" "newcomment" t put comment-region pvs-command editing global-set-key "\3;"] 4) load("pvs-load" nil nil nil) load-with-code-conversion("/usr/lib64/pvs/emacs/go-pvs.el" "/usr/lib64/pvs/emacs/go-pvs.el" nil t) command-line-1(("-load" "/usr/lib64/pvs/emacs/go-pvs.el")) command-line() normal-top-level()
I'm not yet sure what is causing that. I haven't had time to dig into it much yet, hopefully next week.
I admit that I am entirely ignorant of how the gating tests work. I need to learn. Pointers to documentation would be great.
On Wed, Jul 20, 2022 at 3:37 PM Kevin P. Fleming kpfleming@redhat.com wrote:
This week my F36 system got upgraded to Emacs version 28, so it's already in F36. How is that possible?
It's possible because we generally rely on packagers to Do The Right Thing™. There aren't technical restrictions like in some of our enterprise-oriented downstream distros. Policy[1] says "we should avoid major updates of packages within a stable release". In practice, maintainers will make major version bumps because 1. upstream doesn't have a clear major/minor release numbering scheme, 2. it's easier on the packager, and/or 3. they don't believe it introduces incompatibilities.
In this particular case, since the update[2] got sufficient karma, there was nothing to stop it. This is a good opportunity to remind all of us to avoid major version bumps in stable releases where possible. Packagers running with updates-testing enabled might help catch some of these things as well, although there are disadvantages to that, too.
As Dan mentioned in a reply, adding some gating tests to catch the specific breakages here will help prevent this in the future. If you want to add CI gating to your packages, see the CI docs[3].
[1] https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#stable-releases [2] https://bodhi.fedoraproject.org/updates/FEDORA-2022-d75f0c2a4a [3] https://docs.fedoraproject.org/en-US/ci/gating/
On Mon, 18 Jul 2022, Marcus Müller wrote:
Since the pgtk toolkit supports both X and wayland under the hood, I'd very much propose that we do not only package an emacs-pgtk binary, but also, that it becomes what you get by default (i.e. when you install and run `emacs`).
The emacs developers discourage use of the GTK-only build on X11. Perhaps we will want a wrapper to select the most suitable binary.
Oh, I wasn't aware of that, is there somewhere I can read up on that?
On 23.07.22 01:37, Peter Oliver wrote:
On Mon, 18 Jul 2022, Marcus Müller wrote:
Since the pgtk toolkit supports both X and wayland under the hood, I'd very much propose that we do not only package an emacs-pgtk binary, but also, that it becomes what you get by default (i.e. when you install and run `emacs`).
The emacs developers discourage use of the GTK-only build on X11. Perhaps we will want a wrapper to select the most suitable binary.
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Sat, 23 Jul 2022, Marcus Müller wrote:
On 23.07.22 01:37, Peter Oliver wrote:
The emacs developers discourage use of the GTK-only build on X11. Perhaps we will want a wrapper to select the most suitable binary.
Oh, I wasn't aware of that, is there somewhere I can read up on that?
See https://lists.gnu.org/archive/html/emacs-devel/2022-04/msg00761.html
Uff, that thread has been a … sobering read, on a technical and human level.
Thank you for linking me to it!
Best regards, Marcus
On 26.07.22 09:58, Peter Oliver wrote:
On Sat, 23 Jul 2022, Marcus Müller wrote:
On 23.07.22 01:37, Peter Oliver wrote:
The emacs developers discourage use of the GTK-only build on X11. Perhaps we will want a wrapper to select the most suitable binary.
Oh, I wasn't aware of that, is there somewhere I can read up on that?
See https://lists.gnu.org/archive/html/emacs-devel/2022-04/msg00761.html
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Mon, 2022-07-18 at 13:29 -0400, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/Emacs_28
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.
== Summary ==
Update GNU Emacs to 28.1 release. This release includes a wide variety of new features, including native compilation of Lisp files.
== Owner ==
- Name: [[User:Bhavin192| Bhavin Gandhi]]
- Email: bhavin192@fedoraproject.org
== Detailed Description ==
The Emacs package will be updated to 28.1 release of GNU Emacs. This will have native compilation feature enabled, and will package additional natively compiled Lisp files.
Does this add a Requires: on libgccjit, or just a BuildRequires: on libgccjit?
I'm merely curious (as the upstream libgccjit maintainer).
Dave
David Malcolm dmalcolm@redhat.com writes:
On Mon, 2022-07-18 at 13:29 -0400, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/Emacs_28
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.
== Summary ==
Update GNU Emacs to 28.1 release. This release includes a wide variety of new features, including native compilation of Lisp files.
== Owner ==
- Name: [[User:Bhavin192| Bhavin Gandhi]]
- Email: bhavin192@fedoraproject.org
== Detailed Description ==
The Emacs package will be updated to 28.1 release of GNU Emacs. This will have native compilation feature enabled, and will package additional natively compiled Lisp files.
Does this add a Requires: on libgccjit, or just a BuildRequires: on libgccjit?
It adds a requires as well: ❯ ldd (which emacs)|grep gcc libgccjit.so.0 => /lib64/libgccjit.so.0 (0x00007fd0d463d000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fd0d4622000)
❯ rpm -qR emacs|grep gcc libgcc_s.so.1()(64bit) libgcc_s.so.1(GCC_3.0)(64bit) libgcc_s.so.1(GCC_3.3.1)(64bit) libgccjit libgccjit.so.0()(64bit) libgccjit.so.0(LIBGCCJIT_ABI_0)(64bit) libgccjit.so.0(LIBGCCJIT_ABI_1)(64bit) libgccjit.so.0(LIBGCCJIT_ABI_11)(64bit) libgccjit.so.0(LIBGCCJIT_ABI_13)(64bit) libgccjit.so.0(LIBGCCJIT_ABI_14)(64bit)
Cheers,
Dan
On Fri, 2022-07-22 at 22:50 +0200, Dan Čermák wrote:
David Malcolm dmalcolm@redhat.com writes:
On Mon, 2022-07-18 at 13:29 -0400, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/Emacs_28
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.
== Summary ==
Update GNU Emacs to 28.1 release. This release includes a wide variety of new features, including native compilation of Lisp files.
== Owner ==
- Name: [[User:Bhavin192| Bhavin Gandhi]]
- Email: bhavin192@fedoraproject.org
== Detailed Description ==
The Emacs package will be updated to 28.1 release of GNU Emacs. This will have native compilation feature enabled, and will package additional natively compiled Lisp files.
Does this add a Requires: on libgccjit, or just a BuildRequires: on libgccjit?
It adds a requires as well: ❯ ldd (which emacs)|grep gcc libgccjit.so.0 => /lib64/libgccjit.so.0 (0x00007fd0d463d000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fd0d4622000)
❯ rpm -qR emacs|grep gcc libgcc_s.so.1()(64bit) libgcc_s.so.1(GCC_3.0)(64bit) libgcc_s.so.1(GCC_3.3.1)(64bit) libgccjit libgccjit.so.0()(64bit) libgccjit.so.0(LIBGCCJIT_ABI_0)(64bit) libgccjit.so.0(LIBGCCJIT_ABI_1)(64bit) libgccjit.so.0(LIBGCCJIT_ABI_11)(64bit) libgccjit.so.0(LIBGCCJIT_ABI_13)(64bit) libgccjit.so.0(LIBGCCJIT_ABI_14)(64bit)
Thanks!
...and it's nice to see the ABI versioning metadata [1] making it into the RPM metadata.
Dave
[1] https://gcc.gnu.org/onlinedocs/jit/topics/compatibility.html
From the 28.1 NEWS file: this seems to be a breaking change:
** The WHEN argument of 'make-obsolete' and related functions is mandatory.
The use of those functions without a WHEN argument was marked obsolete back in Emacs 23.1. The affected functions are: 'make-obsolete', 'define-obsolete-function-alias', 'make-obsolete-variable', 'define-obsolete-variable-alias'.
which if I am not wrong probably caused several of emacs-* packages to FTBFS in the mass rebuild. (Unfortunately the build.log's only refer to the line-number in the elisp files: dunno if that can be improved?)
Jens
Hello,
My package (emacs-vm) was one of the ones that broke with the upgrade to Emacs 28 in F36. I'm trying to get it to work again.
One of the issues is that it shows up a large number of warnings. After some time I've now understood this is because of the new native compilation feature. Since my package doesn't include any *.eln files and Emacs will do the compilation on first use, and put in the home directory. The VM package has a lot of old code that triggers warnings. Previously those have only shown up at build time, and I have hoped for upstreams to some day fix them. Now they will also show up at run time, which obviously is a more annoying user experience.
That brought up a question: what should Emacs add-on packages do when it comes to native compilation? Should they build and bundle native code? If I understand it correctly, that would mean a new patch build of Emacs itself would also require a rebuild of all add-on packages. Or should we let Emacs recompile native files at run time? That would make the recompilation at Emacs upgrades automatic, but it would on the other hand put a copy of all used libraries in each user's home directory.
I checked the packaging guidelines (https://docs.fedoraproject.org/en-US/packaging-guidelines/Emacs/) but it didn't mention anything around this as far as I could tell. (It still talks about xemacs which has been retired from the distribution, which tells me it hasn't been updated very recently.)
To make things worse for me, with some updates VM initially works after issuing the warnings, but doesn't work on the second start of Emacs, when it doesn't have to recompile the code. But that's a different story.
On Tue, Aug 9, 2022 at 4:56 PM Göran Uddeborg goeran@uddeborg.se wrote:
That brought up a question: what should Emacs add-on packages do when it comes to native compilation? Should they build and bundle native code? If I understand it correctly, that would mean a new patch build of Emacs itself would also require a rebuild of all add-on packages. Or should we let Emacs recompile native files at run time? That would make the recompilation at Emacs upgrades automatic, but it would on the other hand put a copy of all used libraries in each user's home directory.
Good point - I feel it probably makes sense yes.
I checked the packaging guidelines (https://docs.fedoraproject.org/en-US/packaging-guidelines/Emacs/) but it didn't mention anything around this as far as I could tell. (It still talks about xemacs which has been retired from the distribution, which tells me it hasn't been updated very recently.)
If there is consensus on native compilation of elisp packages, then the Emacs guidelines should indeed be updated. I guess then the packages would become arch'ed.
I feel the bigger problem is that many of the emacs lisp packages in Fedora are out of date. The general recommendation is to use Emacs' own packaging system(s) to install elisp, though I appreciate some people may prefer to use a distro package.
Jens
Hi Göran,
Also did you see https://bugs.launchpad.net/vm/+bug/1979048 ? It might help you.
On Tue, Aug 9, 2022 at 4:56 PM Göran Uddeborg goeran@uddeborg.se wrote:
My package (emacs-vm) was one of the ones that broke with the upgrade to Emacs 28 in F36. I'm trying to get it to work again.
One of the issues is that it shows up a large number of warnings. After some time I've now understood this is because of the new native compilation feature. Since my package doesn't include any *.eln files and Emacs will do the compilation on first use, and put in the home directory. The VM package has a lot of old code that triggers warnings. Previously those have only shown up at build time, and I have hoped for upstreams to some day fix them. Now they will also show up at run time, which obviously is a more annoying user experience.
Do you want to try adding native compilation your package?
Jens
Jens-Ulrik Petersen skrev:
Also did you see https://bugs.launchpad.net/vm/+bug/1979048 ? It might help you.
Thanks for the pointer.
I haven't looked at that particular report yet. I have tried building Mark Diekhans' branch "vm-emacs-28" instead of trunk. (Mark is involved in the bug report I see.) That branch works on the first start but all the warnings that get shown instead of the message and one has to manually fix the presentation buffer.
On the second start however, when there are eln files in the home directory, it fails to load complaining about the function "load" having been called with 0 arguments. If I disable native compilation, it keeps on working but the warning messages gets in the way every time.
That is how far I have got. It's been a busy week, at work and otherwise, since I discovered this and I haven't had time to do much more debugging.
Do you want to try adding native compilation your package?
I would like to in the long run, but my primary goal of course is to get it working at all.
Jens-Ulrik Petersen skrev:
Do you want to try adding native compilation your package?
As it turns out, emacs-vm might not be the best package for this experiment. I could not get VM to work with native compilation. Instead, I had to turn the native compilation off completely for all vm*.el files before I could get emacs-vm usable again.
My guess is that it is related to (some of) the warnings issued during compilation. It will be a significant work to get it up to date with the pretty dormant upstreams. It is thus not a good candidate as a guinea pig for bundling native-compiled eln files in add-on packages.
devel@lists.stg.fedoraproject.org
-
Ben Cotton -
Dan Čermák -
David Malcolm -
Göran Uddeborg -
Jens-Ulrik Petersen -
Jerry James -
Kevin P. Fleming -
Marcus Müller -
Peter Oliver -
Stephen Smoogen