Package Details: emacs-git 30.0.50.169253-1

Git Clone URL: https://aur.archlinux.org/emacs-git.git (read-only, click to copy)
Package Base: emacs-git
Description: GNU Emacs. Development master branch.
Upstream URL: http://www.gnu.org/software/emacs/
Keywords: development editor IDE text
Licenses: GPL3
Conflicts: emacs
Provides: emacs
Submitter: toropisco
Maintainer: toropisco
Last Packager: toropisco
Votes: 107
Popularity: 1.93
First Submitted: 2014-01-05 02:05 (UTC)
Last Updated: 2023-10-14 18:36 (UTC)

Required by (313)

Sources (2)

Pinned Comments

toropisco commented on 2017-06-30 19:14 (UTC) (edited on 2022-05-15 13:26 (UTC) by toropisco)

This PKGBUILD is a work in progress. If you find PACKAGING bugs, please let me know ASAP.

Upstream bugs are to be reported upstream. Check out the emacs-devel archives to confirm if this is an already known bug. In fact... Why are you not subscribed to emacs-devel?. Also check the emacs-bug-tracker archives.

Reporting bugs: Write to the Emacs Bug Tracker and report it there. Or, better yet, use the debbugs client included with the text editor. You will find instructions at https://debbugs.gnu.org/. Good luck!

If you confirm it is a packaging bug, you are welcome to report it here.

Yaourt and other automated tools users BEWARE! This PKGBUILD is written with hand updating in mind and I won't fix bugs arising from such use. Besides, cloning the same repository time and time again from a non-profit such as the GNU Project/FSF gives out a very low image of you.

Latest Comments

« First ‹ Previous 1 .. 6 7 8 9 10 11 12 13 14 15 16 .. 39 Next › Last »

toropisco commented on 2021-06-15 00:55 (UTC)

A quick hack, not a proper solution as it would require some new functions and code reshuffling to have a proper cache, be it in a system-wide location in /var/cache or the user home directory, under .emacs, and a way to incrementally update already compiled files if the runtime version or the lisp file version changes.

nowayman commented on 2021-06-14 21:22 (UTC)

Solving that upstream bug will be very difficult and I'll wait for an upstream solution

Apparently it was trivial to work around.

https://github.com/emacs-mirror/emacs/commit/663fb3b774887d3d15a6791c3f35af56daa3c676

Rebuilt from current master and everything appears to be working as expected.

Thanks for the reply and maintaining this script.

toropisco commented on 2021-06-13 14:03 (UTC) (edited on 2021-06-13 20:05 (UTC) by toropisco)

@nowayman, but of course it will. There's one thing I've learned in some 30 years plus of using and being the administrator of Unix and Unix-like multi-user servers and individual workstations: Never f*k with system directories.

Solving that upstream bug will be very difficult and I'll wait for an upstream solution. In the meantime my suggestions and be advised I don't recommend nor endorse you use them, I'll throw my experience behind a big no:

  • Install emacs with its own group and read-write permissions to the group. Add users to that group so that they can happily JIT compile system elisp files.

  • Install emacs with suid root giving users the chance to JIT compile on demand system elisp files and f*k up anything they would like to edit and save.

There are two reasonable solutions:

  • Precompile ALL system elip files, the option is already given in the PKGBUILD (AOT). Takes a long time but it is worth it.

  • Use sudo.

nowayman commented on 2021-06-13 13:35 (UTC) (edited on 2021-06-13 13:41 (UTC) by nowayman)

PKGBUILD Commit dca21d8 (Change behavior of changing directory ownership during packaging) breaks JIT native compilation on my system. Emacs installs fine, but when any packages along /usr/share/emacs/28.0.50/lisp/* are loaded, the JIT compilation kicks in and throws a file-error due to directory permissions.

Compiling /usr/share/emacs/28.0.50/lisp/emacs-lisp/backtrace.el...
/usr/share/emacs/28.0.50/lisp/emacs-lisp/backtrace.el: Error: File error Creating file with prefix

This error message is incomplete, but that's a separate upstream issue. You can get the full error by manually attempting to compile any of those files from a shell prompt. e.g.

$ emacs -batch -l comp -f batch-native-compile
/usr/share/emacs/28.0.50/lisp/progmodes/etags.el

Which will throw:

Debugger entered--Lisp error: (file-error
"/usr/share/emacs/28.0.50/lisp/progmodes/etags.el" "Creating file with prefix"
"Permission denied" "/usr/share/emacs/28.0.50/lisp/progmodes/etags.elc")
 signal(file-error ("/usr/share/emacs/28.0.50/lisp/progmodes/etags.el"
 "Creating   file with prefix" "Permission denied"
 "/usr/share/emacs/28.0.50/lisp/progmodes/etags.elc"))
 comp--native-compile("/usr/share/emacs/28.0.50/lisp/progmodes/etags.el")
 batch-native-compile()
 command-line-1(("-l" "comp" "-f" "batch-native-compile"
 "/usr/share/emacs/28.0.50/lisp/progmodes/etags.el"))
 command-line()
 normal-top-level()

EDIT:

Looks like Eli may consider this an upstream bug altogether. Upstream bug report:

https://lists.gnu.org/archive/html/bug-gnu-emacs/2021-06/msg00654.html

ykelvis commented on 2021-06-05 15:28 (UTC)

hi there, i think systemd should be add to makedepends. without it, group games wont be created, which causes chown root:games to fail when building the package in a clean chroot.

toropisco commented on 2021-06-03 01:21 (UTC)

Your argument is a false dilemma and it stinks of appeal to ignorance.

If you don't like the ability to customize it to your needs, write and maintain your own version. As easy as that.

cobaltspace commented on 2021-06-03 00:57 (UTC)

My point was that enabling/disabling lto is a setting inside makepkg.conf, so it shouldn't be set inside a package, unless a package needs to explicitly disable it, similar to packages using -j1 because -jN isn't supported. lto can be enabled in makepkg.conf, so it doesn't need to be in the PKGBUILD.

toropisco commented on 2021-06-02 13:32 (UTC)

@cobaltspace lto is not enabled in the new makepkg.conf file. Unless you did in the past and forgot about it, the only plausible explanation for your alternate reality assertion. :-)

Compare your local file to this one:

https://github.com/archlinux/svntogit-packages/blob/packages/pacman/trunk/makepkg.conf

cobaltspace commented on 2021-06-02 04:24 (UTC)

Now that setting lto is part of makepkg.conf, maybe the setting should be removed from this pkgbuild.

« First ‹ Previous 1 .. 6 7 8 9 10 11 12 13 14 15 16 .. 39 Next › Last »