F37 proposal: Emacs 28 (Self-Contained Change proposal)

[Ben Cotton]

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(a)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`.


-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis

[Marcus Müller]

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(a)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`.
>
>

[Jens-Ulrik Petersen]

On Tue, Jul 19, 2022 at 5:14 AM Marcus Müller <marcus(a)hostalia.de&gt; 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

[Marcus Müller]

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(a)hostalia.de&gt; 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(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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/[e-mail]
> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

[Kevin P. Fleming]

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?

-- 
Kevin P. Fleming
He/Him/His
Principal Program Manager, RHEL
Red Hat US/Eastern Time Zone

[Jerry James]

On Wed, Jul 20, 2022 at 1:38 PM Kevin P. Fleming <kpfleming(a)redhat.com&gt; 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.
-- 
Jerry James
http://www.jamezone.org/

Confusion on pre-implemented Emacs 28 proposal (was: Re: F37 proposal: Emacs 28 (Self-Contained Change proposal))

[Marcus Müller]

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?
>

[Dan Čermák]

Hi Kevin and all,

"Kevin P. Fleming" <kpfleming(a)redhat.com&gt; 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

[Stephen Smoogen]

On Wed, 20 Jul 2022 at 16:12, Dan Čermák <dan.cermak(a)cgc-instruments.com&gt;
wrote:

>  Hi Kevin and all,
>
>  "Kevin P. Fleming" <kpfleming(a)redhat.com&gt; 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?


-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren

[Stephen Smoogen]

On Thu, 21 Jul 2022 at 08:43, Stephen Smoogen <ssmoogen(a)redhat.com&gt; wrote:

>  On Wed, 20 Jul 2022 at 16:12, Dan Čermák <dan.cermak(a)cgc-instruments.com&gt;
>  wrote:
>
> > Hi Kevin and all,
> >
> > "Kevin P. Fleming" <kpfleming(a)redhat.com&gt; 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?
>
>  
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.


-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren

[Jerry James]

On Wed, Jul 20, 2022 at 2:10 PM Dan Čermák
<dan.cermak(a)cgc-instruments.com&gt; 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.
-- 
Jerry James
http://www.jamezone.org/

[Peter Oliver]

On Wed, 20 Jul 2022, Dan Čermák wrote:

>  After the Emacs 28 PR got merged, I went
>  ahead, built Emacs in Fedora 36 as well and submitted it as an
>  update 
Why, by the way?  This isn’t intended to be a veiled criticism, I’m genuinely interested.

-- 
Peter Oliver

[Ben Cotton]

On Wed, Jul 20, 2022 at 3:37 PM Kevin P. Fleming <kpfleming(a)redhat.com&gt; 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/

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis

[Peter Oliver]

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.

-- 
Peter Oliver

[Marcus Müller]

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(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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/[e-mail]
> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

[Peter Oliver]

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

-- 
Peter Oliver

[Marcus Müller]

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(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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/[e-mail]
> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

[David Malcolm]

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(a)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

[Dan Čermák]

David Malcolm <dmalcolm(a)redhat.com&gt; 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(a)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

[David Malcolm]

On Fri, 2022-07-22 at 22:50 +0200, Dan Čermák wrote:
>  David Malcolm <dmalcolm(a)redhat.com&gt; 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(a)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

[Jens-Ulrik Petersen]

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

[Göran Uddeborg]

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.

[Jens-Ulrik Petersen]

On Tue, Aug 9, 2022 at 4:56 PM Göran Uddeborg <goeran(a)uddeborg.se&gt; 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

[Jens-Ulrik Petersen]

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(a)uddeborg.se&gt; 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

[Göran Uddeborg]

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.

[Göran Uddeborg]

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.