Package Details: emacs-gcc-wayland-devel-bin 28.1.50.151702-1

Git Clone URL: https://aur.archlinux.org/emacs-gcc-wayland-devel-bin.git (read-only, click to copy)
Package Base: emacs-gcc-wayland-devel-bin
Description: GNU Emacs. Development native-comp branch and pgtk branch combined, served as a binary.
Upstream URL: https://github.com/mpsq/emacs-gcc-wayland-devel-builder
Keywords: emacs
Licenses: GPL3
Conflicts: emacs, emacs-27-git, emacs-git, emacs-seq, emacs26-git
Provides: emacs, emacs-seq
Replaces: emacs-git, emacs-seq, emacs26-git, emacs27-git
Submitter: mpsq
Maintainer: mpsq
Last Packager: mpsq
Votes: 33
Popularity: 1.76
First Submitted: 2020-12-03 15:47 (UTC)
Last Updated: 2022-05-17 23:40 (UTC)

Latest Comments

1 2 3 Next › Last »

mpsq commented on 2022-03-03 10:26 (UTC)

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

CYS commented on 2022-03-03 04:21 (UTC)

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

declanqian commented on 2021-12-26 08:55 (UTC)

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

vhoss-aur commented on 2021-12-26 08:17 (UTC)

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

declanqian commented on 2021-12-17 09:49 (UTC)

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

mpsq commented on 2021-08-22 11:23 (UTC)

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

ironborn commented on 2021-08-19 08:41 (UTC)

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.

Crandel commented on 2021-06-30 09:03 (UTC)

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

mpsq commented on 2021-06-28 10:10 (UTC)

@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

crashandburn4 commented on 2021-06-23 11:10 (UTC)

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?