Arch Linux User Repository

@CYS Great idea, thanks! I just added your modification.

I found the filename of the downloaded tarball is something like 28.**.tar.gz, which is hard to determine which package it belongs to.

As quoted from Arch wiki:

The downloaded source filename must be unique because the SRCDEST directory can be the same for all packages. For instance, using the version number of the project as a filename potentially conflicts with other projects with the same version number. In this case, the alternative unique filename to be used is provided with the syntax source=('unique_package_name::file_uri'); e.g. source=("$pkgname-$pkgver.tar.gz::https://github.com/coder/program/archive/v$pkgver.tar.gz").

I would suggest:

diff --git a/PKGBUILD b/PKGBUILD
index 504c84c..1ff91c4 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -14,7 +14,7 @@ provides=('emacs' 'emacs-seq')
 conflicts=('emacs' 'emacs26-git' 'emacs-27-git' 'emacs-git' 'emacs-seq')
 replaces=('emacs26-git' 'emacs27-git' 'emacs-git' 'emacs-seq')

-source=("https://github.com/mpsq/emacs-gcc-wayland-devel-builder/releases/download/$pkgver/$pkgver.tar.gz")
+source=("$pkgname-$pkgver.tar.gz::https://github.com/mpsq/emacs-gcc-wayland-devel-builder/releases/download/$pkgver/$pkgver.tar.gz")
 sha512sums=("94775d04d6e6b35e814156baa0f9da946d63b240c0f9cbf28ae608a4cd4182e36cc03f658555d936ffa38ced9fd28691124f8a4dd72c1f443c1f6f23039133d5")

 package() {

Confirmed, it works. Thanks :+1 @vhoss-aur

There is a pull request for emacs-libvterm that should fix the issue mentioned by @declanqian.

Helpful comment in relevant github issue: https://github.com/akermu/emacs-libvterm/issues/559#issuecomment-997473811

Relevant pull request: https://github.com/akermu/emacs-libvterm/pull/562

vterm refuse to build against the this latest version(emacs-gcc-wayland-devel-bin 28.0.90.151420-1)

Fatal error 11: Segmentation fault
Backtrace:
/usr/bin/emacs(emacs_backtrace+0xff)[0x56036c7cecff]
/usr/bin/emacs(terminate_due_to_signal+0x79)[0x56036c69e328]
/usr/bin/emacs(+0x1ab95a)[0x56036c7ce95a]
/usr/lib/libpthread.so.0(+0x13870)[0x7f2eb9ae9870]
/home/declan/.config/emacs/var/straight/build-28.0.90/vterm/vterm-modu
/usr/bin/emacs(Fmodule_load+0x7b6)[0x56036c8ad6b6]
/usr/bin/emacs(Fload+0x1195)[0x56036c89fac5]
/usr/bin/emacs(save_match_data_load+0x76)[0x56036c8a8726]
/usr/bin/emacs(Frequire+0x447)[0x56036c880c37]
/usr/bin/emacs(funcall_subr+0x110)[0x56036c866880]
/usr/bin/emacs(Ffuncall+0x4cc)[0x56036c86557c]
/usr/bin/emacs(exec_byte_code+0x96e)[0x56036c8c7e4e]
/usr/bin/emacs(eval_sub+0x9ad)[0x56036c86813d]
/usr/bin/emacs(+0x27f18b)[0x56036c8a218b]
/usr/bin/emacs(Fload+0x10bd)[0x56036c89f9ed]
/usr/bin/emacs(save_match_data_load+0x76)[0x56036c8a8726]
/usr/bin/emacs(Fautoload_do_load+0x268)[0x56036c867388]
/usr/lib/emacs/28.0.90/x86_64-pc-linux-gnu/../../../../bin/../lib/emac
cafc76]
/usr/bin/emacs(funcall_subr+0xe7)[0x56036c866857]
/usr/bin/emacs(Ffuncall+0x4cc)[0x56036c86557c]
/usr/lib/emacs/28.0.90/x86_64-pc-linux-gnu/../../../../bin/../lib/emac
d_command_0+0x19e)[0x7f2eafcaf5be]
/usr/bin/emacs(funcall_subr+0x110)[0x56036c866880]
/usr/bin/emacs(Ffuncall+0x4cc)[0x56036c86557c]
/usr/bin/emacs(Ffuncall_interactively+0xda)[0x56036c86194a]
/usr/bin/emacs(funcall_subr+0xcc)[0x56036c86683c]
/usr/bin/emacs(Ffuncall+0x4cc)[0x56036c86557c]
/usr/bin/emacs(Fapply+0x43f)[0x56036c865a1f]
/usr/bin/emacs(Fcall_interactively+0x5af)[0x56036c861fef]
/usr/lib/emacs/28.0.90/x86_64-pc-linux-gnu/../../../../bin/../lib/emac
cafd61]
/usr/bin/emacs(funcall_subr+0xe7)[0x56036c866857]
/usr/bin/emacs(Ffuncall+0x4cc)[0x56036c86557c]
/usr/bin/emacs(+0x1818b3)[0x56036c7a48b3]
/usr/bin/emacs(internal_condition_case+0x11d)[0x56036c86c05d]
/usr/bin/emacs(command_loop_2+0x2e)[0x56036c7a39de]
/usr/bin/emacs(internal_catch+0x120)[0x56036c86b310]
/usr/bin/emacs(+0x18098c)[0x56036c7a398c]
/usr/bin/emacs(recursive_edit_1+0x7e)[0x56036c7a378e]
/usr/bin/emacs(Frecursive_edit+0x180)[0x56036c7b68e0]
/usr/bin/emacs(+0x17e121)[0x56036c7a1121]
/usr/lib/libc.so.6(__libc_start_main+0xd5)[0x7f2eb7b57b25]
/usr/bin/emacs(_start+0x2e)[0x56036c69f1ae]
...
Segmentation fault (core dumped)

Here are backtrace from gdb

#0  0x00007fffd6ecdc7a in emacs_module_init (ert=<optimized out>)
    at /home/declan/.config/emacs/var/straight/build-28.0.90/vterm/vterm-module.c:1404
#1  0x00005555557de6b6 in Fmodule_load ()
#2  0x00005555557d0ac5 in Fload ()
#3  0x00005555557d9726 in save_match_data_load ()
#4  0x00005555557b1c37 in Frequire ()
#5  0x0000555555797880 in funcall_subr ()
#6  0x000055555579657c in Ffuncall ()
#7  0x00005555557f8e4e in exec_byte_code ()
#8  0x000055555579913d in eval_sub ()
#9  0x000055555579e101 in Feval ()
#10 0x00007fffd6ee1b7a in top_level_run ()
    at /home/declan/.config/emacs/eln-cache/28.0.90-15314d31/vterm-a307bbd5-55c982d4.eln
#11 0x000055555580942f in load_comp_unit ()
#12 0x000055555580a17b in Fnative_elisp_load ()
#13 0x00005555557d0b1c in Fload ()
#14 0x00005555557d9726 in save_match_data_load ()
#15 0x0000555555798388 in Fautoload_do_load ()
#16 0x00007fffe6979c76 in F636f6d6d616e642d65786563757465_command_execute_0 ()
    at /usr/lib/emacs/28.0.90/x86_64-pc-linux-gnu/../../../../bin/../lib/emacs/28.0.90/native-lisp/28.0.90-15314d31/preloaded/simple-fab5b0cf-24f63bd9.eln
#17 0x0000555555797857 in funcall_subr ()
#18 0x000055555579657c in Ffuncall ()
#19 0x00007fffe69795be in F657865637574652d657874656e6465642d636f6d6d616e64_execute_extended_command_0 ()
    at /usr/lib/emacs/28.0.90/x86_64-pc-linux-gnu/../../../../bin/../lib/emacs/28.0.90/native-lisp/28.0.90-15314d31/preloaded/simple-fab5b0cf-24f63bd9.eln
#20 0x0000555555797880 in funcall_subr ()
#21 0x000055555579657c in Ffuncall ()
#22 0x000055555579294a in Ffuncall_interactively ()
#23 0x000055555579783c in funcall_subr ()

@ironborn emacs-git is, by definition, master. This package is based on the branch pgtk (rebased frequently from master), so differences are expected.

This package is vanilla Emacs, straight from the upstream branch. We do not patch it, we do not amend anything. If you find an issue, please use M-x report-emacs-bug.

That being said, considering how popular this package is, and how common your bug seems to be, I would be inclined to think that the issue is within your config.

My hyper key definitions under wayland/sway aren't working with this package. For example, keybinding "H-o" interpreted as "o". emacs-git works fine with the same config and environment.

Hi @mpsq, with the latest update everything works fine, thank you!

@crashandburn4, @Crandel, @ees and @mklsls

This bug should now be fixed in latest release (28.0.50.149085), cf. commit https://github.com/flatwhatson/emacs/commit/a4fb5811fab64b7437fa47239d5aae39ba3ed82a. Let me know if it works :).

Extra details available at: https://debbugs.gnu.org/db/49/49118.html

Hi, I'm also having the same issues:

Compiling /usr/share/emacs/28.0.50/lisp/net/dbus.el...
/usr/share/emacs/28.0.50/lisp/net/dbus.el: Error: File error Opening output file

It can be worked around by messing with the directory perms in /usr/share/emacs/28.0.50/lisp or messing with users/groups, but is this the intended solution? from reading emacs-git and your comment, it sounds like it should be fixed?

Hi @mpsq. I removed package, removed all caches, including native-comp cache and install it again but still have this errors every time I start emacs

TLDR: it works!

I thought I tried that this morning and to my surprise it didn't work. Switched to emacs-git and IIRC it didn't work either initially, but after another uninstall/reinstall it worked. Now I'm back on emacs-gcc-wayland-devel-bin and it works too. Soo not sure what that was... I probably just did something dumb, but thought I'd mention it in case it's a real thing that others will hit too.

Thanks for the link ees. It seems to be an issue with upstream and it looks like it was fixed already with https://github.com/emacs-mirror/emacs/commit/663fb3b774887d3d15a6791c3f35af56daa3c676. The latest version of this package should have the fix too, removing / installing emacs-gcc-wayland-devel-bin should be enough to fix the problem. Can you confirm that it is the case?

I'm seeing the same issue as @Crandel. Also seeing it with https://aur.archlinux.org/packages/emacs-git/; there's some relevant discussion over there.

Every time I start emacs I got a lot of errors in Async-native-compile-log buffer like this

Compiling /usr/share/emacs/28.0.50/lisp/emacs-lisp/pcase.el...
/usr/share/emacs/28.0.50/lisp/emacs-lisp/pcase.el: Error: File error Opening output file
Compiling /usr/share/emacs/28.0.50/lisp/wid-edit.el...
/usr/share/emacs/28.0.50/lisp/wid-edit.el: Error: File error Opening output file

All these files exists and readable.

Did you also install libgccjit? You will need the version 11, it is a mandatory dependency to this package.

Also, please do not flag this package as out-of-date if it is actually not the case.

There is a problem with this package in Manjaro

emacs: /usr/lib/libgccjit.so.0: version `LIBGCCJIT_ABI_14' not found (required by emacs)

Hey guys, Emacs upstream was updated recently (compilation flags) and I just reflected the changes in this binary. If you had issues with doom-emacs (doom upgrade), or native-comp in general, this is now fixed.

@mpsq I think I am having strange upscaling issues from using a 4k monitor. There is an open issue thread about it here: https://github.com/masm11/emacs/issues/90

EDIT: This issue has been resolved.

@jeslie0 This is very stange, I open svg files on a daily basis and never had this issue. Is there anything special with your Emacs setup? Does it happen for all svgs? Are you zoomed-in?

I'm having an issue where .svg files are blurry when viewed from inside Emacs (using "emacs -Q" also). It looks like an instance of the bug described here: https://emacs.stackexchange.com/questions/55305/svg-image-display-blurry

Is this a known bug or is it affecting anyone else?

Thank you for maintaining this packages. I installed emacs fresh from this package to solve the blurry problem with xwayland. So far, everything works perfectly.

@mpsq I can confirm that rolling back to 6d6b07b793f2c7d993fe238f99a63c4644dd44ed fixed the problem. Thanks for the help!

@bienjensu Fair enough, I tried and I can reproduce the issue.

I checked and this is a problem with Emacs itself, if you try the last version (of this pkg) everything is ok. The regression is from upstream and there is not much I can do to fix it. You should be able to roll-back to the last version though.

I might add additional checks in my building script, make sure that Emacs starts without warnings/errors before pushing a new version.

@mpsq Hello, yes I'm running without any config at all right now in order to diagnose problems.

Hi Edward, I am not sure what the issue is from the top of my head. Maybe we can "work backwards": did you try to run vanilla Emacs? (without your personal config)

The error you are facing seems to be related to https://github.com/jwiegley/emacs-async. Are you using this as part of your Emacs config by any chance?

Hi, I'm getting errors with this. Everything is left at default in the PKGBUILD, my pkgmake.conf only changes -j and march=native on MAKEFLAGS. These errors repeat every time that after emacs is launched something starts native compilation (following the startpage link to the tutorial, for instance). *Warnings*:

Warning (comp): Debugger entered--Lisp error: (file-error "Opening output file" "Cannot overwrite file" "/usr/share/emacs/28.0.50/lisp/emacs-lisp/cl-lib.el...") Disable showing Disable logging

*Async-native-compile-log*:

Debugger entered--Lisp error: (file-error "Opening output file" "Cannot overwrite file" "/usr/share/emacs/28.0.50/lisp/emacs-lisp/cl-lib.el...")
signal(file-error ("Opening output file" "Cannot overwrite file" "/usr/share/emacs/28.0.50/lisp/emacs-lisp/cl-lib.el..."))
byte-compile-file("/usr/share/emacs/28.0.50/lisp/emacs-lisp/cl-lib.el")
#f(compiled-function (filename) "Byte-compile FILENAME spilling data from the byte compiler." #<bytecode 0x15639fb902450803>)("/usr/share/emacs/28.0.50/lisp/emacs-lisp/cl-lib.el")
apply(#f(compiled-function (filename) "Byte-compile FILENAME spilling data from the byte compiler." #<bytecode 0x15639fb902450803>) "/usr/share/emacs/28.0.50/lisp/emacs-lisp/cl-lib.el" nil)
comp-spill-lap-function("/usr/share/emacs/28.0.50/lisp/emacs-lisp/cl-lib.el")
comp-spill-lap("/usr/share/emacs/28.0.50/lisp/emacs-lisp/cl-lib.el")
#f(compiled-function (pass) #<bytecode 0x8df95ff29d600bb>)(comp-spill-lap)
mapc(#f(compiled-function (pass) #<bytecode 0x8df95ff29d600bb>) (comp-spill-lap comp-limplify comp-fwprop comp-call-optim comp-ipa-pure comp-cond-cstr comp-fwprop comp-dead-code comp-tco comp-fwprop comp-remove-type-hints comp-final))
comp--native-compile("/usr/share/emacs/28.0.50/lisp/emacs-lisp/cl-lib.el" t)
eval-buffer(#<buffer  *load*> nil "/tmp/emacs-async-comp-cl-lib-OWDUvK.el" nil t)  ; Reading at buffer position 1385
load-with-code-conversion("/tmp/emacs-async-comp-cl-lib-OWDUvK.el" "/tmp/emacs-async-comp-cl-lib-OWDUvK.el" nil t)
command-line-1(("-l" "/tmp/emacs-async-comp-cl-lib-OWDUvK.el"))
command-line()
normal-top-level()

These repeat for all files emacs is attempting to native comp. I've already tried completely clearing out all configuration files, purging my /usr/lib/emacs and /usr/share/emacs, and reinstalling to no avail.