Package Details: emacs-git

Git Clone URL: (read-only, click to copy)
Package Base: emacs-git
Description: GNU Emacs. Development master branch.
Upstream URL:
Keywords: development editor IDE text
Licenses: GPL3
Provides: emacs
Replaces: emacs
Submitter: toropisco
Maintainer: toropisco
Last Packager: toropisco
Votes: 103
Popularity: 1.86
First Submitted: 2014-01-05 02:05 (UTC)
Last Updated: 2022-06-08 16:15 (UTC)

Required by (424)

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

dr460nf1r3 commented on 2022-06-08 14:06 (UTC) (edited on 2022-06-08 14:06 (UTC) by dr460nf1r3)

It seems a new makedep is missing: configure: error: The following required libraries were not found: libXpm Maybe some development libraries/packages are missing? To build anyway, give: --with-xpm=ifavailable

VitalyR commented on 2022-06-03 20:00 (UTC) (edited on 2022-06-03 20:02 (UTC) by VitalyR)

Why remove the AOT configuration in the recent commits? It seems that we still need this option (NATIVE_FULL_AOT) to compile the lisp code to native code.


FabioLolix commented on 2022-05-28 16:59 (UTC)

All pkgbuild can be corrected, ffmpeg variants are usually correct and there are many, can't see why can't do the same

toropisco commented on 2022-05-28 16:48 (UTC)

This pkgbuild (and all the emacs variants) only need to provides and conflicts emacs, not provide, conflicts and replace every variant

Exactly. Your statement applies to a perfect world but I don't work with ideal monads.

FabioLolix commented on 2022-05-28 16:34 (UTC)

This pkgbuild (and all the emacs variants) only need to provides and conflicts emacs, not provide, conflicts and replace every variant

toropisco commented on 2022-05-15 22:04 (UTC)

Thaodan, why do you think you have the right answer?

Thaodan commented on 2022-05-15 21:55 (UTC)

Why is gsettings disabled in any case? It only requires glib and doesn't have any gnome dependency necessarily. GSettings is supposed to replace XRessources for pgtk.

toropisco commented on 2022-05-15 16:43 (UTC)

I've added a temporary fix to the PKGBUILD but it royally screws those who, like myself, do not like having the editor font depend on a desktop global setting. At least it works, for now.

snackattack commented on 2022-05-15 16:40 (UTC)

It looks like they are addressing this problem upstream now:

Apologies for the noise of reporting it here -- this appears to be an upstream problem, not a packaging problem.

snackattack commented on 2022-05-15 13:31 (UTC)

@Rogach thanks, you're right -- I accidentally copy-pasted the most recent commit in my log instead of 526e9758, which was the most recent one to touch xsettings.c.

Rogach commented on 2022-05-15 06:53 (UTC)

@snackattack I've bisected the issue, and it seems it was introduced in commit 526e9758 (bd464297bd seems unrelated, it's just some lisp code tweaks).

snackattack commented on 2022-05-15 00:11 (UTC)

I'm getting an error in xsettings.c (error: 'font_options' undeclared) when trying to build this.


This may be related to the recent commit bd464297bd in the emacs master branch.

If I remove --without-gsettings from the PKGBUILD then the package builds successfully:

diff --git a/PKGBUILD b/PKGBUILD
index 89cece3..c6e4b97 100644
@@ -239,7 +239,6 @@ build() {
 # If you insist you'll need to read that bug report in *full*.
 # Good luck!
-   --without-gsettings


MormonJesus69420 commented on 2022-04-08 18:20 (UTC)

That's understandable, enjoy your holidays!

toropisco commented on 2022-04-08 18:04 (UTC)

Hmmm... MormonJesus69420 you are correct after all. I don't have much time this week and I'm not even reading non-work email with much attention. I was left with with your first message and jumbled memories. I'll fix it during Easter week.

MormonJesus69420 commented on 2022-04-08 17:05 (UTC)

Hi toropisco! I'm not sure I understand you correctly. Do you mean I read the PKGBUILD wrongly? As far as I can tell the line 232 doesn't need to be there. However I have very little experience with both writing and reading PKGBUILD files, so I would appreciate it if you could elaborate on your comment. Thank you for your time in replying to my comment.

toropisco commented on 2022-04-08 16:45 (UTC)

MormonJesus69420 I just stole some time to examine my project files. You need a new recipe for your reading glasses. :-)

toropisco commented on 2022-04-07 16:26 (UTC)

Hi MormonJesus69420, it is simply that the option did exist last time I did a full walkthrough on the script. This is the master development source code tip after all.

I'll remove it next time I do a new cleanup.

MormonJesus69420 commented on 2022-04-07 13:38 (UTC) (edited on 2022-04-07 13:38 (UTC) by MormonJesus69420)

Hey I was looking at the PKGBUILD for this package and noticed something that I think is off.

On line 232 we have following:


Which as far as I am aware enables sound by default, even though there's an option on line 64 to enable the alsa support. The script checks for that ALSA flag further down on lines 280-284, as follows:

if [[ $ALSA == "YES" ]]; then
    _conf+=( '--with-sound=alsa' );
    _conf+=( '--with-sound=no' );

Shouldn't therefore the line 232 be removed?

clangdo commented on 2022-04-04 21:15 (UTC)

The https URL I can currently access is:, notice the extra /git/ in the link. I would recommend using this if it works because at least you have some TLS on top of the connection. Otherwise you have NO verification that the code your running is from the GNU project. Another option would be to do GPG verification, but every commit on the master branch probably isn't signed?

See this gist for why you should prefer https

xircon commented on 2022-03-22 19:32 (UTC)

Something is obviously wrong with my set-up, am investigating.

xircon commented on 2022-03-22 19:28 (UTC)

What? I just cloned the PKGBUILD!

toropisco commented on 2022-03-22 19:07 (UTC)

@xircon Why do you insist on using https for cloning? I updated the PKGBUILD to use the protocol at least six months ago.

xircon commented on 2022-03-22 18:56 (UTC) (edited on 2022-03-22 19:04 (UTC) by xircon)

I still have problems:

makepkg -si
==> Making package: emacs-git (Tue 22 Mar 2022 18:55:11 GMT)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
  -> Cloning emacs-git git repo...
Cloning into bare repository '/home/xircon/git/emacs-git/emacs-git'...
fatal: repository '' not found
==> ERROR: Failure while downloading emacs-git git repo

This fixes it (for me!):


toropisco commented on 2022-03-22 14:13 (UTC) (edited on 2022-03-22 14:14 (UTC) by toropisco)

@xircon No, the PKGBUILD doesn't need updating. the git server works for me as of the time I'm posting this answer.

xircon commented on 2022-03-22 12:03 (UTC)


Then the PKGBUILD needs updating.

pancho commented on 2022-03-22 11:04 (UTC) (edited on 2022-03-25 11:57 (UTC) by pancho)


(With Palpatine's voice): "You are looking for this".

xircon commented on 2022-03-22 08:22 (UTC)

Am getting a 404 on

toropisco commented on 2022-03-17 16:48 (UTC) (edited on 2022-03-17 16:55 (UTC) by toropisco)

@cvelteren I updated the PKGBUILD a couple of days ago. Shame on you! :-P

cvelteren commented on 2022-03-17 15:16 (UTC) (edited on 2022-03-17 16:11 (UTC) by cvelteren)

~~Hi, are the x11 dependencies required? I am running sway and I am getting configure: error: Gtk+ wanted, but it does not compile, see config.log. Maybe some x11-devel files missing? when installing.~~ it was my python environment that messed with things, it is compiling now. Thanks!

piater commented on 2022-03-13 10:19 (UTC)

FWIW, I just rebuilt emacs-git with PGTK, and I did not observe any broken menus (under sway).

VitalyR commented on 2022-03-06 02:15 (UTC)

@fosskers It's not true. libgccjit is provided as a standalone package in the core repo:

fosskers commented on 2022-03-05 21:48 (UTC)

libgccjit is now provided by the official gcc package.

karloguidoni commented on 2022-02-15 14:58 (UTC)

Love this community. Another kindly guy on the libgccjit page just instructs me on how to solve this too. Thanks to all of you.

VitalyR commented on 2022-02-15 14:28 (UTC) (edited on 2022-02-15 14:44 (UTC) by VitalyR)

If you met the libgccjit requires gcc-libs=11.1.0 problem and you don't know how to handle this, here is a quick solution for you:

  • Uninstall libgccjit and emacs-git:
sudo pacman -R libgccjit emacs-git
  • Roll your arch linux, just
sudo pacman -Syyu

Hopefully Arch will enable jit in the gcc package then we don't need to install libgccjit any more. Someone is working on that:

titaniumbones commented on 2022-02-15 14:15 (UTC)

I believe the whole toolchain is in the process of upgrading. I would expect it to take a while to shake out.

karloguidoni commented on 2022-02-15 13:41 (UTC)

I'm getting the same error reported by @kuba-orlik. Apparently, the problem is the upgrade of gcc-libs, which libgccjit depends on.

kuba-orlik commented on 2022-02-15 12:45 (UTC)

I get this error when trying to install emacs-git:

 -> Could not find all required packages:
    gcc-libs=11.1.0 (Wanted by: emacs-git -> libgccjit)

When trying to install libgccjit I get this error:

 -> Could not find all required packages:
    gcc-libs=11.1.0 (Wanted by: libgccjit

pancho commented on 2022-01-14 06:13 (UTC)

There is an open issue¹ for producing a libgccjit official package, so I suggest putting a vote on it (couldn't hurt).


toropisco commented on 2022-01-05 13:15 (UTC)

@lyjdwh The only reason is that libgccjit is in the AUR. TBH, I enable it in my own builds. Perhaps I should enable it for everybody, shouldn't I?

lyjdwh commented on 2022-01-05 12:56 (UTC) (edited on 2022-01-05 12:57 (UTC) by lyjdwh)

I notice emacs-native-comp-git was deleted. I wonder why emacs-git doesn't turn on the JIT option as it can speed up emacs. @vorbote

toropisco commented on 2021-12-21 12:28 (UTC)

@VitalyR I have use for Xinput2 ELISP regardless the GUI. And I don't use Wayland, so there.

VitalyR commented on 2021-12-21 09:21 (UTC)

AFAIK xinput2 could do nothing with pgtk. They should not be turned on together.

ynakao commented on 2021-12-21 02:54 (UTC)

I don't know why (maybe enabling pgtk config?), but the libxpm error has gone after the latest change[1].


Thaodan commented on 2021-12-19 23:06 (UTC)

Also the JIT option isn't exactly right since emacs uses LIBGCCJIT to compile lisp aot instead of jit like it was before when using elisp byte code.

Thaodan commented on 2021-12-19 22:59 (UTC) (edited on 2021-12-19 22:59 (UTC) by Thaodan)

Hey I've add pgtk support to the pkgbuild. See here:

diff --git a/PKGBUILD b/PKGBUILD
index caa195b..1f76e06 100644
@@ -41,6 +41,10 @@ AOT=YES              # Precompile all included elisp. It takes a long time.

 CLI=              # CLI only binary.

+PGTK=             # use pure GTK build without reliance on X libs (Wayland support)
+                  # (requires cairo) - Experimental]
 GPM=              # Mouse support in Linux console using gmpd.

 NOTKIT=           # Use no toolkit widgets. Like B&W Twm (001d sk00l).
@@ -135,6 +139,8 @@ elif [[ $NOTKIT == "YES" ]]; then
 elif [[ $LUCID == "YES" ]]; then
   depends+=( 'dbus' 'hicolor-icon-theme' 'libxinerama' 'libxfixes' 'lcms2' 'librsvg' 'xaw3d' 'libxrandr' );
   makedepends+=( 'xorgproto' );
+elif [[ $PKGTK == "YES" ]]; then
+  depends+=( 'gtk3' );
   depends+=( 'gtk3' );
   makedepends+=( 'xorgproto' );
@@ -154,7 +160,7 @@ if [[ $ALSA == "YES" ]]; then

-if [[ ! $NOCAIRO == "YES" ]] && [[ ! $CLI == "YES" ]] ; then
+if [[ $PGTK == YES ]] || [[ ! $NOCAIRO == "YES" ]] && [[ ! $CLI == "YES" ]] ; then
   depends+=( 'cairo' );

@@ -252,11 +258,13 @@ elif [[ $NOTKIT == "YES" ]]; then
   _conf+=( '--with-x-toolkit=no' '--without-toolkit-scroll-bars' '--without-xft' '--without-xaw3d' );
 elif [[ $LUCID == "YES" ]]; then
   _conf+=( '--with-x-toolkit=lucid' '--with-xft' '--with-xaw3d' );
+elif [[ $PGTK == "YES" ]]; then
+  _conf+=( '--with-pgtk3' '--without-xaw3d' );
   _conf+=( '--with-x-toolkit=gtk3' '--without-xaw3d' );

-if [[ $NOCAIRO == "YES" || $CLI == "YES" ]]; then
+if [[ ! $PGTK == YES ]] || [[ $NOCAIRO == "YES" || $CLI == "YES" ]]; then
   _conf+=( '--without-cairo' );

haawda commented on 2021-12-18 18:17 (UTC)

the feature/pgtk branch has been merged into master.

johnvardas commented on 2021-12-14 12:32 (UTC)

thanks for the feedback

toropisco commented on 2021-12-14 11:31 (UTC) (edited on 2021-12-14 11:31 (UTC) by toropisco)

<sarcasm> johnvardas, if you cannot tell the difference between a packaging error and an upstream bug in a development tip branch, then kid, emacs-git is not for you. No, no emacs-git branch will work for you. <sarcasm/>

Please use emacs-pretest, thank you.

ynakao commented on 2021-12-05 21:53 (UTC)

Sorry, but why was libxpm removed from dependency at the latest change[1]? build() fails again in configure process. Am I missing something?


totsilence commented on 2021-12-05 21:26 (UTC)

Hey, in the latest version i think $SOUND should be $ALSA in line 263. Cheers!

ynakao commented on 2021-12-04 07:06 (UTC) (edited on 2021-12-04 07:07 (UTC) by ynakao)

In chroot environment, build() fails due to missing libxpm[1]. This is caused by removing m17n-lib[2] which depends on libxpm via gd[3]. So, I guess libxpm should be added to depends.

configure: error: The following required libraries were not found:
Maybe some development libraries/packages are missing?
To build anyway, give:
as options to configure.
==> ERROR: A failure occurred in build().




pancho commented on 2021-12-03 06:41 (UTC) (edited on 2021-12-03 06:42 (UTC) by pancho)

Well, I'll just say that the emacs package on extra dropped libmagick6 on Aug 2020, as can be seen on the git history¹. No mention of imagemagick or libmagick in the current PKGBUILD ². ;-)



toropisco commented on 2021-12-02 19:51 (UTC)

@zhenya1007 Don't tempt me! I've waited long enough to drop ImageMagick. I'll look at your patches this weekend. Cheers.

zhenya1007 commented on 2021-12-02 19:47 (UTC)

In a (perhaps misguided) effort to reduce the number of libraries needed to compile/install Emacs, I have added two knobs: one for GPM and another one for sound/ALSA. Here is the change for the GPM knob:

diff --git a/PKGBUILD b/PKGBUILD
index fd2a07a..c63d62c 100644
@@ -64,6 +64,7 @@ MAGICK=           # ImageMagick 7 support. Deprecated (read the logs).
                   # -->>If you just *believe* you need ImageMagick, you don't.<<--

 NOGZ="YES"        # Don't compress .el files.
+GPM=              # Support mouse in the Linux console via libgpm.

@@ -78,7 +79,7 @@ pkgdesc="GNU Emacs. Development master branch."
-depends_nox=('alsa-lib' 'gnutls' 'libxml2' 'jansson' 'gpm')
+depends_nox=('alsa-lib' 'gnutls' 'libxml2' 'jansson')
 depends=("${depends_nox[@]}" 'm17n-lib' 'libotf' 'harfbuzz')
 provides=('emacs' 'emacs26-git' 'emacs-27-git' 'emacs-seq' 'emacs-nox')
@@ -179,6 +180,14 @@ fi
 if [[ $DOCS_PDF == "YES" ]]; then
   makedepends+=( 'texlive-core' );
+if [[ $GPM == "YES" ]]; then
+  if [[ $CLI == "YES" ]]; then
+    depends_nox+=( 'gpm' );
+  else
+    depends+=( 'gpm' );
+  fi

@@ -271,6 +280,11 @@ if [[ $NOGZ == "YES" ]]; then
   _conf+=( '--without-compress-install' );

+if [[ $GPM == "YES" ]]; then
+    true
+  _conf+=( '--without-gpm' );
 # ctags/etags may be provided by other packages, e.g, universal-ctags

And here is the ALSA/sound knob:

diff --git a/PKGBUILD b/PKGBUILD
index c63d62c..681b86f 100644
@@ -65,6 +65,8 @@ MAGICK=           # ImageMagick 7 support. Deprecated (read the logs).

 NOGZ="YES"        # Don't compress .el files.
 GPM=              # Support mouse in the Linux console via libgpm.
+SOUND=            # Support for sound.
+                  # The only useful values are "YES" and "alsa". The two are equivalent.

@@ -79,7 +81,7 @@ pkgdesc="GNU Emacs. Development master branch."
-depends_nox=('alsa-lib' 'gnutls' 'libxml2' 'jansson')
+depends_nox=('gnutls' 'libxml2' 'jansson')
 depends=("${depends_nox[@]}" 'm17n-lib' 'libotf' 'harfbuzz')
 provides=('emacs' 'emacs26-git' 'emacs-27-git' 'emacs-seq' 'emacs-nox')
@@ -188,6 +190,15 @@ if [[ $GPM == "YES" ]]; then
     depends+=( 'gpm' );
+if [[ $SOUND == "YES" || $SOUND == [aA][lL][sS][aA] ]]; then
+  if [[ $CLI == "YES" ]]; then
+    depends_nox+=( 'alsa-lib' );
+  else
+    depends+=( 'alsa-lib' );
+  fi

@@ -224,7 +235,6 @@ build() {
-    --with-sound=alsa
 # Beware
 # dconf and gconf break font settings you set in ~/.emacs.
@@ -285,6 +295,13 @@ if [[ $GPM == "YES" ]]; then
   _conf+=( '--without-gpm' );
+if [[ $SOUND == "YES" || $SOUND == [aA][lL][sS][aA] ]]; then
+    _conf+=( '--with-sound=alsa' );
+    _conf+=( '--with-sound=no' );
 # ctags/etags may be provided by other packages, e.g, universal-ctags

If you would like me to provide the patches via some alternate means, please let me know.

zhenya1007 commented on 2021-12-02 19:34 (UTC)

FWIW, I couldn't agree more with the decision to drop GTK+2, libotf and m17n-flt. Now, if we could only get rid of Imagemagick for good... ;-)

zhenya1007 commented on 2021-10-05 23:13 (UTC) (edited on 2021-10-05 23:15 (UTC) by zhenya1007)

If set CLI="YES" (am I the only user of that option?! :P), it sets $pkgname to emacs-git-nox, derives emacs-git-nox.install as the name of the $install file, and fails when it discovers that said $install file doesn't exist.

My suggestion is to hard-code emacs-git.install as the name of the $install file, to wit:

@@ -75,7 +75,7 @@ replaces=('emacs' 'emacs26-git' 'emacs-27-git' 'emacs-seq' 'emacs-nox')
 # If Savannah fails for reasons, use Github's mirror

pancho commented on 2021-10-01 10:46 (UTC) (edited on 2021-10-01 10:47 (UTC) by pancho)

Hi, folks.

I've forked¹ this repo to track the just-created emacs-28² release branch.

Also, I've enabled JIT and AOT, as well as parallel compilation.

Thanks, and happy hacking!



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.

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

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"
 command-line-1(("-l" "comp" "-f" "batch-native-compile"


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

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:

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.

toropisco commented on 2021-05-09 14:56 (UTC)

@amyiris [this comes from the retired university professor speaking on his soap box] you are confused and trying to generalize from incomplete information. Rust is not C nor ELisp. You need to familiarize with your tools before you can bend them to your will. And learn to use all the hammers in the shed, each one has a purpose.

amyiris commented on 2021-05-09 14:46 (UTC)

@Hi-Angel while I'm aware of this, some packages don't expect this and as a result break. Rust projects in particular do when they compile multiple libraries and then a binary where all depend on each other. Many of these launch all their cargo targets via a Makefile and since Rust compiles using multiple threads (when compiling dependencies that is) there's no point to splitting it across threads.

Hi-Angel commented on 2021-05-09 09:59 (UTC)

@amyiris AFAIK you're supposed to have a MAKEFLAGS="-jN" in your makepkg.conf. At least I have had this in makepkg.conf for ages, and the wiki seems to confirm that.

amyiris commented on 2021-05-09 03:25 (UTC)

Many other AUR packages compile with -j or -j $(nproc) in order to accelerate compile times on large builds. Emacs is an especially large build and takes forever to compile on a single thread, even on fast machines (I run an AMD Ryzen 7 1700X). Having this by default - and maybe making a switch to disable it in the PKGBUILD - would be incredibly useful.

MuffinBomber commented on 2021-04-13 14:54 (UTC)

Finally, I suggest this patch that would allow users to select whether they want to native compile all built-in elisp ahead of time. Sorry for the constant pings, I should've thought about this sooner. This can also wait until the weekend to avoid annoying users with the daily version bumps.

Currently, only the bare minimum is natively compiled and users need to set comp-deferred-compilation to a non-nil value in their init. More info here:

diff --git a/PKGBUILD b/PKGBUILD
index 1fe96e8..22102d3 100644
@@ -26,6 +26,10 @@ GOLD=             # Use the gold linker.
 LTO="YES"         # Enable link-time optimization. Read emacs's INSTALL before
                   # attempting to use it with clang.
 JIT=              # Enable native just-in-time compilation. libgccjit is in AUR.
+AOT=              # Native compile all Emacs (takes a long time!).
+                  # If this is disabled, Emacs will defer the native compilation
+                  # of an elisp file until it is actually used.
+                  # comp-deferred-compilation has to be non nil if AOT is off.
 CLI=              # CLI only binary.
 NOTKIT=           # Use no toolkit widgets. Like B&W Twm (001d sk00l).
 LUCID=            # Use the lucid, a.k.a athena, toolkit. Like XEmacs, sorta.
@@ -267,9 +271,12 @@ _conf+=('--program-transform-name=s/\([ec]tags\)/\1.emacs/')
   # Please note that incremental compilation implies that you
   # are reusing your src directory!
-  #
-  make

+  if [[ $JIT == "YES" ]] && [[ $AOT == "YES" ]]; then
+    make NATIVE_FULL_AOT=1;
+  else
+    make;
+  fi
   # You may need to run this if 'loaddefs.el' files become corrupt.
   #cd "$srcdir/emacs-git/lisp"
   #make autoloads

MuffinBomber commented on 2021-04-12 11:48 (UTC)

Thanks for the quick patches! Currently, even non native-compile users would pull in the libgccjit dependency. Wouldn't this be a bit better?

diff --git a/PKGBUILD b/PKGBUILD
index 662e600..e94ed6f 100644
@@ -107,9 +107,9 @@ else

-if [[ $CLI == "YES" ]]; then
+if [[ $CLI == "YES" ]] && [[ $JIT == "YES" ]]; then
   depends_nox+=( 'libgccjit' );
+elif [[ $JIT == "YES" ]]; then
   depends+=( 'libgccjit' );

MuffinBomber commented on 2021-04-11 11:49 (UTC)

You missed a 'libgccjit' dependency for the native compilation build with the latest update.

There's a 'emacs-native-comp-git' PKGBUILD that closely follows this one, but uses the native-comp branch. You can check what's needed for the 'native-comp' build there.

MuffinBomber commented on 2021-04-09 14:48 (UTC)

The native-compilation feature is getting merged onto master next weekend (

It would be a good idea to add a NATIVE_COMPILATION variable that would enable '--with-native-compilation' option.

esrevinu commented on 2021-03-21 18:04 (UTC)

conf in the below part of PKGBUILD looks like a typo of _conf.

# ctags/etags may be provided by other packages, e.g, universal-ctags

But with the typo fixed, build failed. Finally, the following modification works.

 # ctags/etags may be provided by other packages, e.g, universal-ctags

toropisco commented on 2021-03-19 22:45 (UTC) (edited on 2021-03-19 22:47 (UTC) by toropisco)

zhenya1007 thanks for the patch. I took the chance to fix some standing bugs and it is already up. Please give it a good beating and report back.

zhenya1007 commented on 2021-03-19 16:50 (UTC)

Would you consider something like the patch below which (IMO) makes a few improvements to the CLI-only build? If you like the idea but object to some aspects of execution, I am happy to work with you to make adjustments. TIA!

diff --git a/PKGBUILD b/PKGBUILD
index 9ea97ca..bbe70b7 100644
@@ -48,16 +48,20 @@ NOGZ="YES"        # Don't compress .el files.

+if [[ $CLI == "YES" ]]; then
+   pkgname="emacs-nox-git"
 pkgdesc="GNU Emacs. Development master branch."
 arch=('x86_64' )
 license=('GPL3' )
-depends=('alsa-lib' 'gnutls' 'libxml2' 'jansson' 'm17n-lib' 'libotf' 'harfbuzz' 'gpm')
+nox_depends=('alsa-lib' 'gnutls' 'libxml2' 'jansson' 'gpm') # when $CLI is "YES"
+depends=("${nox_depends[@]}" 'm17n-lib' 'libotf' 'harfbuzz')
 provides=('emacs' 'emacs-seq')
-conflicts=('emacs' 'emacs26-git' 'emacs-27-git' 'emacs-seq')
+conflicts=('emacs' 'emacs26-git' 'emacs-27-git' 'emacs-seq', 'emacs-nox')
 replaces=('emacs26-git' 'emacs27-git' 'emacs-seq')
 # If Savannah access is blocked for reasons, use Github instead.
@@ -141,6 +145,10 @@ if [[ $XWIDGETS == "YES" ]]; then

+if [[ $CLI == "YES" ]]; then
+   depends=("${nox_depends[@]}")
 if [[ $DOCS_PDF == "YES" ]]; then
   makedepends+=( 'texlive-core' );
@@ -235,6 +243,10 @@ fi
 if [[ $NOGZ == "YES" ]]; then
   _conf+=( '--without-compress-install' );
+# ctags/etags may be provided by other packages, e.g, universal-ctags

@@ -275,15 +287,6 @@ package() {
   if [[ $DOCS_HTML == "YES" ]]; then make DESTDIR="$pkgdir/" install-html; fi
   if [[ $DOCS_PDF == "YES" ]]; then make DESTDIR="$pkgdir/" install-pdf; fi

-  # remove conflict with ctags package
-  mv "$pkgdir"/usr/bin/{ctags,ctags.emacs}
-  if [[ $NOGZ == "YES" ]]; then
-    mv "$pkgdir"/usr/share/man/man1/{ctags.1,ctags.emacs.1};
-  else
-    mv "$pkgdir"/usr/share/man/man1/{ctags.1.gz,ctags.emacs.1.gz}
-  fi
   # fix user/root permissions on usr/share files
   find "$pkgdir"/usr/share/emacs/ | xargs chown root:root

Hi-Angel commented on 2021-02-23 17:44 (UTC)

Now by default PKGBUILD files will have sh-mode enabled by default, you can also see the bug report:

Oh, this is amazing, thanks!

utkarsh commented on 2021-02-23 17:23 (UTC)

Now by default PKGBUILD files will have sh-mode enabled by default, you can also see the bug report:

utkarsh commented on 2021-02-20 04:27 (UTC) (edited on 2021-02-20 04:27 (UTC) by utkarsh)

@vorbote Oh! Thanks for notifying about the package:

@Hi-Angle I will try to implement it and keep you updated on the matter.

toropisco commented on 2021-02-19 18:57 (UTC)

@utkarsh, there is a PKGBUILD major mode in AUR that is far more specific than sh-mode. That's why I've never bothered to add an emacs modeline.

Hi-Angel commented on 2021-02-19 18:25 (UTC)

@utkarsh well, you could send a patch upstream to add to sh-mode support for PKGBUILD files. FWIW, I tried doing that after I saw your comment, but I couldn't figure out how sh-script.el defines file-extensions to operate upon.

utkarsh commented on 2021-02-19 17:05 (UTC)

Thanks for maintaining emacs-git!

Since this package is explicitly dealing with Emacs it want you to add the following line on the top of PKGBUILD:

#-*-mode: sh-*-

As the line suggest, it tell Emacs the file is a shell script. Since we are already accepting 'vim' based modification in the last line this can be a quality of life improvement.

toropisco commented on 2021-01-21 13:05 (UTC) (edited on 2021-01-21 13:08 (UTC) by toropisco)

@lordie, I use Linux, I don't do macos. Patches welcome, but don't cross your fingers. As emacs macos builds are different to linux, for very obvious operating system differences, you should develop your own scripts and submit them to the homebew database.

lordie commented on 2021-01-21 04:31 (UTC)

if you have homebrew installed emacs-git/configure will throw an error, "alsa sound support requested but not found". probably an upstream issue.

Hi-Angel commented on 2021-01-02 18:49 (UTC)

No problem, and thank you! Happy new year you too!

toropisco commented on 2021-01-02 18:41 (UTC)

@Hi-Angel, thank you for catching up this bug! Happy new year!

Hi-Angel commented on 2021-01-02 15:01 (UTC)

By the way, given PKGBUILD was inadvertently defaulting to LTO=YES since 2019-10-23 (commit Fix gcc vs clang lfo flags), and no one complained, I think it should be safe to explicitly set LTO=YES as the default.

Hi-Angel commented on 2021-01-02 14:47 (UTC)

Just tried building a debug version, and was getting odd errors about lto not being found on linking stage. Turns out, there's a minor bug in PKGBUILD: the paragraph that checks $LTO enables it disregarding the value. The paragraph should instead look like:

if [[ $LTO == "YES" ]]; then
    if [[ $CLANG != "YES" ]]; then
        CFLAGS+=" -flto -fuse-linker-plugin"
        CXXFLAGS+=" -flto -fuse-linker-plugin"
        CFLAGS+=" -flto"
        CXXFLAGS+=" -flto"

toropisco commented on 2020-05-28 00:13 (UTC)

@iexcel Take upstream bugs to upstream.

iexcel commented on 2020-05-22 19:44 (UTC) (edited on 2020-05-22 19:45 (UTC) by iexcel)

The build fails with clang 10 regardless of LTO enablement. GCC works fine.

  CC       sha512.o
  CC       dtoastr.o
  CC       dtotimespec.o
dtotimespec.c:34:27: warning: implicit conversion from 'time_t' (aka 'long') to 'double' changes value from 9223372036854775807 to 9223372036854775808 [-Wimplicit-int-float-conversion]
  else if (! (sec < 1.0 + TYPE_MAXIMUM (time_t)))
                        ~ ^~~~~~~~~~~~~~~~~~~~~
./intprops.h:58:4: note: expanded from macro 'TYPE_MAXIMUM'
  ((t) (! TYPE_SIGNED (t)                                               \
1 warning generated.
  CC       filemode.o
  CC       filevercmp.o
  CC       gettime.o
  CC       nstrftime.o
  CC       pipe2.o
  CC       qcopy-acl.o
  CC       stat-time.o
  CC       tempname.o
  CC       timespec.o
  CC       timespec-add.o
  CC       timespec-sub.o
  CC       u64.o
  CC       unistd.o
  CC       openat-die.o
  CC       save-cwd.o
  AR       libgnu.a
make[1]: Leaving directory '/home/me/.cache/yay/emacs-git/src/emacs-git/lib'
make -C lib-src all
make[1]: Entering directory '/home/me/.cache/yay/emacs-git/src/emacs-git/lib-src'
  CCLD     etags
error: fallthrough annotation does not directly precede switch label
1 error generated.
make[1]: *** [Makefile:366: etags] Error 1
make[1]: Leaving directory '/home/me/.cache/yay/emacs-git/src/emacs-git/lib-src'
make: *** [Makefile:411: lib-src] Error 2
==> ERROR: A failure occurred in build().
Error making: emacs-git

totsilence commented on 2020-05-07 19:30 (UTC) (edited on 2020-05-08 11:50 (UTC) by totsilence)

Thanks for the update. There is a bug, though: If I set NOCAIRO to "YES" I get:

==> ERROR: depends is not allowed to be empty.

totsilence commented on 2020-04-09 09:21 (UTC) (edited on 2020-04-09 09:22 (UTC) by totsilence)


emacs now builds with cairo by default (if found), so whether or not --with-cairo is added to configure is irrelevant. I suggest to change

if [[ $CAIRO == "yes" ]]; then


if [[ $CAIRO != "yes" ]]; then


titaniumbones commented on 2020-04-08 20:26 (UTC)

I need to experimentally revert some some changes in emacs-git that were made soe time ago (cf. I'm not that familiar with aur -- is it appropriate for me to ask for help here on how to modify package source before running makepkg -si?


toropisco commented on 2020-02-23 13:07 (UTC)

@jilen No, pkgconf is not a build dependency.

If you try to compile a PKGBUILD in Arch without installing the base-devel group, you are doing things wrong.

jilen commented on 2020-02-21 02:13 (UTC)

Notice that, this build depends on pkgconf, which was not listed as a dependency

toropisco commented on 2020-02-17 20:31 (UTC)

@jackrandom no problem. I thought I'd updated the build to disable clang and lto last December, I'll have to upload the new version...

niv commented on 2020-02-16 21:43 (UTC)

If someone is interested, I created emacs27-git [1], which is based on emacs-27 release branch [2] and has LTO and CLANG disabled by default.

@vorbote, I mildly modified your PKGBUILD from here for that, I hope that's okay, else let me know!

[1] [2]

shackra commented on 2020-02-11 05:03 (UTC)

this package is slow and freeze when using lsp-mode but I use the Snap of Emacs for Linux Mint in my work laptop and it do not behave the same as this package installed on my gaming PC

any ideas?

toropisco commented on 2019-12-21 17:37 (UTC)

@haawda thanks for the report. It should be fixed now.

haawda commented on 2019-12-21 15:35 (UTC)

I think compilation of emacs with X support is affected by this major cleanup:

I needed to install xorgproto. namcap does not mention it as dependeanca, so it might only be a makedependancy.

toropisco commented on 2019-11-24 00:58 (UTC)

@Stebalien apparently you didn't read the warnings clearly written at the top of the PKGBUiLD. Did you?

Stebalien commented on 2019-11-23 16:42 (UTC)

Please don't override makepkg config variables. Users specify how they want packages compressed in their makepkg.conf and PKGBUILds shouldn't mess with these settings.

toropisco commented on 2019-11-01 14:40 (UTC)

@cireu, this PKGBUILD reflects my use and taste, not yours.

You are welcome to configure the PKGBUILD anyway you like. That's why I provide configuration flags, unlike the vast majority of packages in core, extra, community and the AUR. If you feel it lacks some extra configuration option, speak with your patch; I'll excersize my privilege to accept it or not.

cireu commented on 2019-11-01 14:32 (UTC)

Why LTO was enabled by default? The install instructment of Emacs reports that LTO is an unstable feature. And I can't find any other evidence to support whether Clang+LTO is no longer experimental.

bezirg commented on 2019-10-29 08:51 (UTC) (edited on 2019-10-29 08:54 (UTC) by bezirg)

Question: is GPM support now a) built-in and not re-configurable with flags or b) completely removed? I see gpm as a dependency so I assume (a).

iexcel commented on 2019-10-23 01:39 (UTC) (edited on 2019-10-23 01:40 (UTC) by iexcel)

CLANG works now (thanks) but with a lot of warnings:

warning: optimization flag '-fuse-linker-plugin' is not supported

maybe just take out the flag if it's not supported anyway?

iexcel commented on 2019-10-22 18:57 (UTC) (edited on 2019-10-22 19:00 (UTC) by iexcel)

if CLANG="YES", the build errors out.

configure: error: C compiler cannot create executables

CjK commented on 2019-09-12 10:41 (UTC)

@maderios I had the same problem with exactly the same test(s) failing (which is bogus, since emacs works perfectly after de-activating checks).

It's probably not useful to keep checks active for now.

maderios commented on 2019-09-08 12:00 (UTC) (edited on 2019-09-08 13:41 (UTC) by maderios)

I got compiling error. I had to disable "TEST". It works.

Without modification: SUMMARY OF TEST RESULTS

Files examined: 255 Ran 3363 tests, 24 failed to run, 3332 results as expected, 0 unexpected, 31 skipped 1 files did not finish: lisp/net/network-stream-tests.log make[2]: *** [Makefile:320: check-doit] Error 2

toropisco commented on 2019-09-05 17:34 (UTC) (edited on 2019-09-05 18:02 (UTC) by toropisco)

[quote] That's a harsh judgement. [/quote]

Considering I've used used ImageMagick since 1989, you can take my word as gospel. :-) BTW, I was using netpbm before that, I still like it better.

Yes. It is deprecated. Search the mailing list too.

mollitz commented on 2019-09-03 14:31 (UTC)

              # ImageMagick 7 support. Deprecated (read the logs). 
              # ImageMagick, like flash, is a bug ridden pest that 
      # won't die;  yet it is useful if you know what you 
      #are doing.

That's a harsh judgement. I did not find any logs giving information about the deprecation and also didnot find any alternative to fixing slowly loading images. Can someone clarify?

cireu commented on 2019-08-08 10:05 (UTC)

Current Emacs master branch use Imagemagick 7 to support --with-imagemagick option, the PKGBUILD still using imagemagick6 and it was removed from Arch repo.

totsilence commented on 2019-07-31 11:19 (UTC) (edited on 2019-09-15 18:10 (UTC) by totsilence)

FYI: I observe crashes due to the addition of the --with-cairo flag in the PKGBUILD. This is in emacs --daemon / emacsclient mode. I will see if I can report the bug upstream.

Edit: Bug is fixed in emacs by now.

stefanc_diff commented on 2019-04-06 09:26 (UTC)

Thanks for the kind words @vorbote , I'm aware of how WIP open source software development works.

I've posted this info in here : - to give you some heads up in case you're planning updating the AUR src code - in case you are part of the upstream emacs devel team or have links to the upstream emacs devel team

I"ll have a look at how to file a bug with the upstream emacs devel team.

toropisco commented on 2019-04-05 21:49 (UTC)

@stefann_inc Upstream bugs are reported upstream. Besides, when you use WIP software, if it breaks you get to keep the pieces.

stefanc_diff commented on 2019-04-05 18:42 (UTC)

FYI: Latest emacs-git from HEAD f2d22273599f96a731e23b2f6d7571af8bb7bb3f fails to build inside an nspawn clean and updated arch chroot, with this missing libgnu.a error:

  GEN      time.h
  GEN      unistd.h
  AR       libgnu.a
ar: fcntl.o: No such file or directory
make[1]: *** [Makefile:103: libgnu.a] Error 1
make: *** [Makefile:410: lib] Error 2
==> ERROR: A failure occurred in build().

Full build log can be found here: - -

As far as pkgfile is able to find only extra/clisp contains this libgnu.a file but even when adding clisp to the depends list emacs-git fails to build.

Haven't been

Rogach commented on 2019-01-30 15:54 (UTC)

Can you please add emacs-seq package to provides array? emacs-seq functionality is bundled inside the new 27th version, so it is not needed anymore.

ykelvis commented on 2018-10-29 06:40 (UTC)

According to wiki, replaces is used to replace any obsolete packages. AUR packages should use conflicts and provides.

haawda commented on 2018-10-05 11:11 (UTC)

Please add



toropisco commented on 2018-07-26 23:31 (UTC)

I don't support AUR helpers for this package in particular.

zhou13 commented on 2018-07-26 22:16 (UTC) (edited on 2018-07-26 22:17 (UTC) by zhou13)

This packages fools some aur helpers such as yay when we change branch to emacs-26:

albert748 commented on 2018-06-23 02:13 (UTC)

please change the line: if [[ BRANCH = "emacs-26" ]]; then

to: if [[ $BRANCH = "emacs-26" ]]; then

d125q commented on 2018-06-14 08:13 (UTC) (edited on 2018-06-14 08:13 (UTC) by d125q)

In _conf+=( '--with-x-toolkit=no' 'without-toolkit-scrollbars' '--with-xft' '--without-xaw3d' );, without-toolkit-scrollbars should be changed to --without-toolkit-scroll-bars. It can also be removed altogether, as it should have no effect (as there is no toolkit in the first place).

Also, [[ $LTO = "yes" ]] should be changed to [[ $LTO = "YES" ]] in

if [[ $LTO = "yes" ]]; then
  export CFLAGS+=" -flto"
  export tXXFLAGS+=" -flto"

bandali commented on 2018-06-11 23:11 (UTC)

Thanks for the updates, but the quotes between the two packages in 'dbus hicolor-icon-theme' are still missing for the $LUCID case.

bandali commented on 2018-06-11 15:20 (UTC)

Indeed, 'high-color-icon-theme' should be 'hicolor-icon-theme', and 'libfixes' should be 'libxfixes'.

rompy commented on 2018-06-11 07:06 (UTC) (edited on 2018-06-11 10:59 (UTC) by rompy)

The depends lines where it contains 'dbus high-color-icon-theme' should be 'dbus' 'hicolor-icon-themes' (for LUCID and NOKIT options).

Else, an error occurs:

==> ERROR: depends contains invalid characters: ' '

Also, libfixes is no longer available in repository.

toropisco commented on 2018-06-04 00:37 (UTC)

blaenk, works for me. Make sure you have the latest version of the PKGBUILD and then uninstall completely (pacman -Rscn) and install again.

blaenk commented on 2018-06-02 17:26 (UTC) (edited on 2018-06-02 17:26 (UTC) by blaenk)

Not sure if it's a bug, but I'm getting this:

==> WARNING: Package contains reference to $srcdir                                                                                                            

VanLaser commented on 2018-05-14 19:27 (UTC)

pkgver() also failed here with error:

ERROR: pkgver is not allowed to contain colons, hyphens or whitespace.

I used the following instead (thanks @CjK for the link):

pkgver() {
  cd "$pkgname"
  ( set -o pipefail
    git describe --long 2>/dev/null | sed 's/\([^-]*-g\)/r\1/;s/-/./g' ||
    printf "r%s.%s" "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)"

CjK commented on 2018-04-19 13:50 (UTC)

Thanks @vorbote for your work on this. I was able to build the latest emacs-26 with this pkgbuild.

However, the pkgver() function didn't work for me. I replaced it with something sane from and then it worked flawlessly.

toropisco commented on 2018-02-13 16:55 (UTC)

OK. It seems there is some corruption in config files after adjusting the detection of libpng in autoconf. Quick fix: Run "make distclean" on the cached sources. Real fix: Delete the src directory.

toropisco commented on 2018-02-12 12:29 (UTC)

When you use development code, if it breaks you get to keep the pieces. You may want to use a checkout before e9ca57cfcbaf1a8dfc6bde5a2afd5f3c7b357cb1 for now. BTW, ALWAYS check the git log before compiline a new binary. Basic "devops".

CjK commented on 2018-02-12 09:04 (UTC) (edited on 2018-02-12 09:07 (UTC) by CjK)

Trying to build emacs-git package today failed for me.

See here for the build error log:

toropisco commented on 2018-02-11 12:31 (UTC)

Now guys, don't ger me wrong. As I said before, the bug is in cask's PKGBUILD. I don't see a reason to accomodate a package that has some specious configuration decisions and failings. If cask's packager contacts me privately I am more than willing to discuss modifications to both his package and my several emacs pkgbuilds (I also maintain emacs-pretest which is a more natural choice to update your elisp code and yet it is a symphony of crickets there).

toropisco commented on 2018-02-11 11:28 (UTC)

sondr3: I see what you mean. The bug is in cask's PKGBUILD. it should not ask for a version. I was necessary four or five years ago, but not anymore.

sondr3 commented on 2018-02-11 10:59 (UTC) (edited on 2018-02-11 11:00 (UTC) by sondr3)

vorbote: Because if you are developing packages for Emacs you use Cask for testing and installing dependencies and emacs-git doesn't work with it because it doesn't provide a proper version, so Cask refuses to install. Not providing a version with this package is pretty silly because you can't use it to test new versions of Emacs with packages you are developing.

toropisco commented on 2018-02-09 19:52 (UTC)

tad: Why? 'Cause 'tis a nice checkbox to tick?

Emacs doesn't provide a library with a specific ABI, unless you are using modules; which you have to maintain yourself at this moment anyway.

tad commented on 2018-02-09 18:30 (UTC)

Can we change to


? Packages like 'cask' depend on 'emacs>=$version', which this package does not satisfy.

Stebalien commented on 2018-01-25 18:31 (UTC)

Still missing patch 3 from the first patch set:

Stebalien commented on 2018-01-23 21:01 (UTC)

Missed one:

(else -> elif)

Stebalien commented on 2018-01-23 20:59 (UTC)



  • Whitespace (git complains)
  • Missing $ in variable
  • Mismatched quotes

toropisco commented on 2018-01-23 14:40 (UTC)

I needed to edit some xmlfiles myself last week and rewrote that part of the PKGBUILD to hardwire both xml2 and jansson. I forgot all about it.

Uploaded the new version earlier today.

toropisco commented on 2018-01-23 14:40 (UTC) (edited on 2018-01-23 14:41 (UTC) by toropisco)

I needed to edit some xml files myself last week and rewrote that part of the PKGBUILD to hardwire both xml2 and jansson. I forgot all about it.

Uploaded the new version earlier today.

maxxcan commented on 2018-01-23 14:35 (UTC)

@vorbote I only notice it like information. If you user eww you need libxml2 support. Maybe Someone don't know it

toropisco commented on 2018-01-23 00:28 (UTC)

@maxxcan read the PKGBUILD. I don't support yaourt nor similar curds.

maxxcan commented on 2018-01-21 20:03 (UTC)

This version is compiled without libxml2 support.

TatriX commented on 2018-01-11 06:36 (UTC)

I'm experiencing slowdown in some aspects with both emacs-26 and master as compared with emacs 25.1 For example "C-x C-f" and "C-h k C-x C-f" works with a noticeable delay.

Does anyone experience something similar?

haawda commented on 2018-01-05 20:54 (UTC) (edited on 2018-01-05 23:33 (UTC) by haawda)

For me imagemagick6 can be used if you change the related section in the PKGBUILD to this:

[[ $MAGICK = "YES" ]]; then

depends+=( 'libmagic6' );

depends+=( 'libjpeg-turbo' 'giflib' );

export PKG_CONFIG_PATH="/usr/lib/imagemagick6/pkgconfig"

elif [[ ! $NOX = "YES" ]]; then

depends+=( 'libjpeg-turbo' 'giflib' ); else



and include a patch for detection:

So the whole PKGBUILD with which I tested the pictures automatically fit into a buffer looks like this:

haawda commented on 2017-12-16 21:42 (UTC) (edited on 2017-12-16 21:48 (UTC) by haawda)

Line 88 looks strange. Shouldn't it be CXXFLAGS?

And after Arch's update to imagemagick 7 emacs' imagemagick support is broken. The build system does not find libmagick6 even if it is there. Edit: Sorry, I overlooked your comment in the PKGBUILD.

titaniumbones commented on 2017-10-17 21:07 (UTC)

hmm, fails for me with: Making package: remacs-git (Tue Oct 17 17:02:14 EDT 2017) ==> Retrieving sources... -> Updating remacs-git git repo... Fetching origin ==> Validating source files with md5sums... remacs-git ... Skipped :: Building remacs-git package(s)... ==> Making package: remacs-git (Tue Oct 17 17:02:16 EDT 2017) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> WARNING: Using existing $srcdir/ tree ==> Starting pkgver()... ==> Updated version: remacs-git ==> Removing existing $pkgdir/ directory... ==> Starting build()... /home/matt/.cache/pacaur/remacs-git/PKGBUILD: line 141: ./configure: No such file or directory ==> ERROR: A failure occurred in build(). Aborting... :: failed to build remacs-git package(s) Not quite sure what's going on?

LindyBalboa commented on 2017-10-12 14:05 (UTC)

Currently failing with: /usr/bin/ld: warning:, needed by /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../lib/, may conflict with /usr/lib/ undefined reference to `hb_font_funcs_set_nominal_glyph_func' /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../lib/ undefined reference to `hb_ot_math_has_data' /usr/lib/ undefined reference to `hb_ft_font_set_load_flags' /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../lib/ undefined reference to `__divmodti4@GCC_7.0.0' /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../lib/ undefined reference to `hb_ot_math_get_glyph_italics_correction' /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../lib/ undefined reference to `hb_ot_math_get_glyph_assembly' /usr/lib/ undefined reference to `hb_buffer_set_cluster_level' /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../lib/ undefined reference to `hb_ot_math_get_constant' /usr/lib/ undefined reference to `hb_font_funcs_set_variation_glyph_func' /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../lib/ undefined reference to `hb_ot_math_get_glyph_variants' collect2: error: ld returned 1 exit status make[1]: *** [Makefile:600: temacs] Error 1 make[1]: Leaving directory '/home/LindyBalboa/.cache/pacaur/emacs-git/src/emacs-git/src' make: *** [Makefile:416: src] Error 2 ==> ERROR: A failure occurred in build(). Aborting...

toropisco commented on 2017-09-29 16:50 (UTC)

@bennya And? Didn't your PKGBUILD updated to HEAD version automatically? Please do not report gratitious out of date problems with VCS packages. I'm talking about ANY VCS package in AUR, not one of mine in particular. Now, if you find a bug in the PKGBUILD, you are more than welcome to send a report and I'll act on it.

toropisco commented on 2017-09-29 16:47 (UTC)

@tad I haven't come across such hard dependencies myself. On the other hand, emacs handles bytecode compiled with older versions of itself just fine.

tad commented on 2017-09-14 19:35 (UTC)

Can you change 'emacs' to "emacs=$pkgver" in the provides=() array? Often packages that depend on emacs specify a version. See for more info.

noch commented on 2017-09-06 15:08 (UTC)

@vorbote Thanks.

bennya commented on 2017-08-22 10:59 (UTC)

Can you shallow clone emacs? It takes so long otherwise. This is how to do it comment out source and md5sums and replace prepare function: prepare() { cd "$srcdir" git clone --depth=1 $pkgname cd "$pkgname" [[ -x configure ]] || ( ./ git && ./ autoconf ) }

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

toropisco commented on 2017-06-30 19:08 (UTC)

@nochiel I examined the configuration options and I have come up with a solution. I'm uploading a new PKGBUILD in a bit.

noch commented on 2017-06-30 19:05 (UTC)

@palopezv Got it. Thanks.

toropisco commented on 2017-06-28 14:19 (UTC)

@nochiel, as you will notice, m17n-libs support is disabled by default; I don't need it so... But you can enable it in the PKGBUILD.

toropisco commented on 2017-06-28 14:17 (UTC)

@nochiel, it is pulled in indirectly by m17n-libs. Has that changed?

noch commented on 2017-06-28 14:16 (UTC)

Should libotf be listed as a dependency?

toropisco commented on 2017-01-26 12:38 (UTC)

Please note that cairo support is *very* experimental. Font corruption will happen sooner or later. If you want the latest and greatest, stick to webkit2gtk support.

corruptmemory commented on 2017-01-20 04:43 (UTC)

So, the problem seems related to harfbuzz and infinality. In my case I removed infinality as per: pacman -S --asdeps freetype2 cairo fontconfig Others reported that rebuilding harfbuzz against infinality worked for them. The test that was failing was testing building against GTK3 and failed: undefined reference to `FT_Get_Var_Blend_Coordinates'

corruptmemory commented on 2017-01-19 14:10 (UTC)

Kinda at a loss here. Trying to install emacs-git and I eventually get: configure: error: Gtk+ wanted, but it does not compile, see config.log. Maybe some x11-devel files missing? ==> ERROR: A failure occurred in build(). Aborting... ==> ERROR: Makepkg was unable to build emacs-git. ==> Restart building emacs-git ? [y/N] ==> ---------------------------------- I figured this was some sort of temporary problem, but it has been giving me this result for a couple of weeks now. The end of the config.log looks like: #define HAVE_RSVG 1 #define HAVE_IMAGEMAGICK 1 #define HAVE_GETADDRINFO_A 1 #define HAVE_GTK3 1 #define GDK_DISABLE_DEPRECATION_WARNINGS 1 #define GLIB_DISABLE_DEPRECATION_WARNINGS 1 configure: exit 1 Halp?

toropisco commented on 2016-11-14 14:06 (UTC)

A heads up: Emacs master has now working systemd integration but the logic to isntall the new user service file is partially broken under Arch. This new PKGBUILD adds a small hack to fix this, therefore it is highly recommended you update to this version or at least peruse the fix at the end of the file.

toropisco commented on 2016-10-28 22:07 (UTC)

Ah, OK. Ricardo Wurmus patches got in a couple of days ago. I'm running the script through namcap to make sure different option combinations work OK and I'll upload the updated version momentarily.

toropisco commented on 2016-10-28 11:44 (UTC) (edited on 2016-10-28 11:45 (UTC) by toropisco)

I'll look into that as soon as possible.

haawda commented on 2016-10-27 22:46 (UTC) (edited on 2016-10-27 22:51 (UTC) by haawda)

Since some very recent commits, emacs with gtk3 and xwidgets enabled introduces webkit2gtk instead of webkitgtk as dependency. The configure script checks for webkitgtk+, but in Arch Linux this seems to mean webkit2gtk. Also, combining gtk2 (i.e. setting gtk3=<empty_string and xwitgets="Yes") is not possible and leads to configure: error: xwidgets requested but gtk3 not used.

csantosb commented on 2016-09-19 09:29 (UTC)

I think you need to remove the line # remove conflict with texinfo rm "$pkgdir"/usr/share/info/ As a reference, look at and

csantosb commented on 2016-09-19 09:28 (UTC)

I think you need to remove the line # remove conflict with texinfo rm "$pkgdir"/usr/share/info/ As a reference, look at and

toropisco commented on 2016-09-13 23:42 (UTC)

@yakshaver Err. No. You are expected to install the base-devel group in order to compile *any* PKGBUILD. Picking and choosing is not really an option.

yakshaver commented on 2016-09-07 21:33 (UTC) (edited on 2016-09-07 21:35 (UTC) by yakshaver)

Ahhh I figured it out. I did not have pkg-config installed, which actually causes any dependency checks to fail.

yakshaver commented on 2016-09-07 21:33 (UTC)

Is anyone else having trouble installing this with error messages about alsa support?

toropisco commented on 2016-08-30 11:59 (UTC)

@urobyd Update what again? Increasing the release number of the PKGBUILD will not change a colon of its contents; unless you have a patch to propose that I will gladly consider.

uroybd commented on 2016-08-30 08:19 (UTC)

Please update it. :)

rhoit commented on 2016-08-27 03:54 (UTC) (edited on 2016-08-27 11:06 (UTC) by rhoit)

UPDATE: Now fixed, there was problem with my git repo, since emacs repo is huge I normally clone it separately with --depth=1, where I change few thing in config, which resulted repo not being updated. ---- recently it I'm having problem with. configure: error: The following required libraries were not found: libjpeg Maybe some development libraries/packages are missing? If you don't want to link with them give --with-jpeg=no as options to configure

toropisco commented on 2016-06-25 15:27 (UTC)

The joys of using the bleeding edge. You get to break your toys and keep the pieces. :-)

haawda commented on 2016-06-24 19:46 (UTC)

The problem went away, I suspect with this commit: So it was an upstream issue obviuosly.

haawda commented on 2016-06-24 16:57 (UTC)

No, I am doing it in a clean chroot using extra-x86_64-build. I am quite sure that my system is messed up in some ways, but isn't this what clean chroots are for?

toropisco commented on 2016-06-24 12:38 (UTC)

Err. No. If you need to install texlive-plainextra to compile the texi source files into pdf means you are trying to do it by hand. NOT SUPPORTED, I'm afraid. Let me explain. Every GNU package texi documentation is written with an especific texinfo.tex version as target and it is always included with the package sources. There is a reason why you use make to generate the documentation! It sets up the proper paths and files to obtain the formatted final documents as intended by upstream. I ran a full build last night in a fresh vm with a fresh chroot and I obtained perfect pdf files without adding texlive-plainextra to the makedepends array just to make sure. The solution to bypass the PKGBUILD (I use it myself): Go into the src directory, run configure, enter the doc subdirectories and run "make pdf". Copy the pdf file somewhere safe and you are done. If this is not the scenario, then you have bigger problems with how you have set up your system. I can't help you there. :-(

haawda commented on 2016-06-24 00:28 (UTC) (edited on 2016-06-24 00:29 (UTC) by haawda)

What I wanted to say in my previous post was: You have in line 56 of your PKGBUILD: if [[ $DOCS_PDF = "YES" ]]; then makedepends+=('texlive-core'); fi This should be if [[ $DOCS_PDF = "YES" ]]; then makedepends+=('texlive-plainextra'); fi This is the case independently of TeXLive 2016 or 2015, so you can do the change right now, no need to wait. texlive-plainextra has 1671,00 KiB, so it is a cheap addition.

toropisco commented on 2016-06-23 16:03 (UTC)

Good for you! I don't use testing usually and I didn't know texlive 2016 was in the repo till I read today's messages to arch-dev-public. Thus, I presumed you were using the upstream binary distribution. Disregard my previous comments, please. I'll make a note to update the emacs' git-based packages I maintain as soon as texlive 2016 enters stable.

haawda commented on 2016-06-23 14:55 (UTC)

My issue with elisp.pdf was solved for me by pulling in the makedependency texlive-plainextra, instead of texlive-core only, and building in clean chroots for [extra] or [testing], both tested. I guess it works because it pulls in the correct file texinfo.tex.

haawda commented on 2016-06-23 09:23 (UTC)

I now treiedin clean chroots for [testing] and [extra], and it is the same.

toropisco commented on 2016-06-23 01:02 (UTC) (edited on 2016-06-23 01:14 (UTC) by toropisco)

""" I had to add an explicite rm "$pkgdir"/usr/share/info/dir """ Update your PKGBUILD checkout. It is apparently incompatible with pacman 5.0 hooks. It means it is several months old. """ And make pdf seems not to work, at least with texlive 2016 """ That usually is a problem with how you set up TexLive's PATH. In particular if you also have installed Arch's TexLive version. Won't be able to test that myself with 2016 for a while, but my experience with previous versions of TeXLive and TeTeX has been so.

haawda commented on 2016-06-22 23:28 (UTC)

I had to add an explicite rm "$pkgdir"/usr/share/info/dir Otherwse I get a file conflict. And make pdf seems not to work, at least with texlive 2016 GEN elisp.pdf /usr/bin/texi2dvi: TeX neither supports -recorder nor outputs \openout lines in its log file make[1]: *** [Makefile:159: elisp.pdf] Fehler 1

bandali commented on 2016-04-26 18:50 (UTC) (edited on 2016-04-26 18:51 (UTC) by bandali)

PKDBUILD has a typo in build(): On line 105, the -- for 'with-xtoolkit=gtk2' is missing.

toropisco commented on 2016-04-03 20:50 (UTC)

Yes. Sorry for the typo; already fixed.

esrevinu commented on 2016-04-03 20:29 (UTC)

[[ -x configure ]] || $( ./ git && ./ autoconf ) This code failed. Do you mean this? [[ -x configure ]] || ( ./ git && ./ autoconf )

toropisco commented on 2016-03-15 18:05 (UTC)

Those who can't compile emacs git master nor emacs 25 git branch, please try with the emacs-pretest package at <>. Thank you.

toropisco commented on 2016-03-04 13:37 (UTC)

The emacs25-git package is mine. But, if you can't compile the master branch, you won't be able to compile the emacs-25 branch. I'll spell it clearly pandeiro: The problem is in your setup or a PEBCAK. I can install a fresh copy of Arch Linux and compile both packages with no problems at all. And I compile them under chroot to make sure that all the dependencies required are correct. In fact, pro-tip, I only keep one copy of the upstream git repo and symlink the directory to the build/development directories.

ryuslash commented on 2016-03-04 11:24 (UTC)

haawda: certainly, it seems there is an emacs25-git package in the aur, I was just trying to help point pandeiro in the right direction. Personally I just appended "#branch=emacs-25" to the SOURCE of this package.

haawda commented on 2016-03-04 10:34 (UTC)

ryulash: it is not forbidden to provide an emacs25(-git) package.

ryuslash commented on 2016-03-04 09:15 (UTC)

If you want to use the latest git version of Emacs you really should be using the "emacs-25" branch, not the "master" branch. At least until Emacs 25 is released.

pandeiro commented on 2016-03-03 17:16 (UTC)

OK vorbote, so this package is "caveat emptor", I get it. I thought I should expect it to be able to build at least. I wonder how else I can get Emacs 25.x on Arch, open to suggestions for a more stable route.

toropisco commented on 2016-03-02 23:56 (UTC) (edited on 2016-03-04 13:38 (UTC) by toropisco)

And back to your scheduled git repo pull. Till Savannah keels over again. ;-)

toropisco commented on 2016-03-02 23:55 (UTC)

@pandeiro then don't use the master branch :-) Seriously though. When you use the master branch you have no guarantee that it will compile at all. If it breaks you get to keep the pieces. Now... Don't you use make bootstrap unless you must; and you'll know if you do. The configuration scripts run make bootstrap if needed and it is only in some corner cases related to unsynced .el .elc files that you really need to run bootstrap. I put forward that if the above is not the case, the problem is somewhere else and may require you reinstall your system; I've had that kind of weirdness arising from filesystem corruption.

pandeiro commented on 2016-03-02 22:22 (UTC)

@verbote Unfortunately none of those suggestions produced a different result than the error I posted below.

toropisco commented on 2016-03-02 17:12 (UTC) (edited on 2016-03-02 17:12 (UTC) by toropisco)

@pandeiro. Delete the src and pkg directories and try again. If trouble persists delete the git repo and download again. Works for me.

pandeiro commented on 2016-03-02 15:35 (UTC)

`makepkg -s` fails for me every time with: ... Dumping under the name emacs Makefile:739: recipe for target 'bootstrap-emacs' failed make[1]: *** [bootstrap-emacs] Segmentation fault (core dumped) make[1]: Leaving directory '/home/mu/emacs-git/src/emacs-git/src' Makefile:398: recipe for target 'src' failed make: *** [src] Error 2 ==> ERROR: A failure occurred in build().

madalu commented on 2016-02-28 16:14 (UTC)

FWIW, the git:// service at Savannah is working at the moment.

toropisco commented on 2016-02-23 13:54 (UTC) (edited on 2016-02-23 13:56 (UTC) by toropisco)

Savannah has been in trouble for the last weeks and the git:// service is gone, who knows for how long. I have switched to use the http interface. I know it is an inconvenience, but a simple edition of the git repo config file fixes it. No need to redownload everything.

zhenya1007 commented on 2015-11-30 16:10 (UTC)

Commit 8e5785c9 introduced a bug: ./configure ${_conf} should instead be ./configure ${_conf[@]} or, equivalently (since the variable expansion isn't inside a double-quoted string) ./configure ${_conf[*]} See:

toropisco commented on 2015-08-26 20:06 (UTC)

I'll go ahead and back out Cairo support for a while. The reason is simple and due to something I missed: Image corruption. I tested EWW and all images broken. Whoever wants sharper fonts will have to play with fontconfig configuration files I'm afraid.

danekl commented on 2015-08-24 16:59 (UTC)

A poll is a great idea! I'd just like to add that I, for certain fonts - the one I use with Emacs being one, have configured fontconfig to disable antialiasing. Perhaps that's the reason the cairo backend is soo much worse in my case. I haven't compared cairo vs xft with antaliased fonts.

toropisco commented on 2015-08-24 16:02 (UTC)

@danekl To me the fonts look shaper with cairo, while thicker and smudgier without it. I like both kinds of display but I agree that it makes text more difficult to read in high resolution screens. I am open to suggestions, but I do want this to be a poll, not a one-sided decision on my part. So, I'd appreciate if the people subscribed to this comments page filled the following poll:

danekl commented on 2015-08-24 14:04 (UTC)

Is it just me or do the fonts look super ugly after enabling cairo?

toropisco commented on 2015-03-29 16:58 (UTC)

@prodigen No. I only support Arch Linux proper. If you want to cross compile to an ARM architecture, you can add it to the architecture array yourself.

commented on 2015-03-29 16:29 (UTC)


toropisco commented on 2015-03-17 13:00 (UTC)

Keep Calm and Wait Until the cl-macs bug is fixed. Else, add #commit=f925fc93bac41d7622d1af927e33b0e738ff55b0 at the end of the source git checkout line and sit tight for a few days.

toropisco commented on 2015-03-16 17:43 (UTC)

@madalu It happens sometimes that new features or wide-ranging bug fixes cause such speed regressions. Also, I hope you are not adding LTO optimization to the PKGBUILD as it is slowing emacs a lot. Hopefully the latter will change when gcc 5.0 is released. Yet, using a snapshot taken today, start up time is the same for me as the previous compile I was using, created on February 28. This using a Core 2 Duo with an Intel gen4 GPU *and* using GNOME Wayland for a desktop. Also, I have uploaded a new PKGBUILD earlier today changing "make" for "make bootstrap", the reason being that if you interrupt the build for some reason (a brief power out in my case this morning, battery is long dead in that laptop) and then you use "makepkg -e" to continue where you left off the compile, the already created loaddefs.el files will break the build at some point or another. This will double configuration time, my apologies for that.

madalu commented on 2015-03-16 03:36 (UTC)

I just rebuilt bleeding edge emacs using the updated package and am finding that my emacs init time increased over ten times (from 1.5 seconds to 13 seconds). This is compared to a build I did on February 4. Are others else experiencing the same?

toropisco commented on 2015-02-02 11:22 (UTC)

@andrej84 No. You never makedepend a PKGBUILD on the base or base-devel groups. It is expected that you, as a knowledgeable and experienced Arch user, install base-devel and read the wiki *well before* you start using AUR and spamming AUR comment sections. I suggest you start by reading and continue from there.

andrej84 commented on 2015-02-02 09:57 (UTC)

Hi guys, I think there should be two more dependencies, autoconf and automake at least, since the compilation fails if they are not there..

csantosb commented on 2015-01-13 18:49 (UTC)

Great packaging, really helpful, thanks ! I am using it adding 'make docs' to build() and 'make DESTDIR="$pkgdir/" install-doc' to package(). This provides up-to-date doc in pdf format, but requires 'texlive'. Hope that helps.

toropisco commented on 2014-12-22 12:20 (UTC)

@esrevinu Thanks for noticing. I thought upstream had already fixed that installation bug, but it seems I simply forgot I already had the directory hierarchy created properly in my system.

esrevinu commented on 2014-12-21 07:48 (UTC)

Bunch of warnings against different ownership of directories under /usr/share/emacs/. I think that the following line is needed to be uncommented. #find "$pkgdir"/usr/share/emacs/ | xargs chown root:root

commented on 2014-12-04 14:10 (UTC)


toropisco commented on 2014-12-01 16:43 (UTC)

@prodigen Thanks for your report! I've revised the PKGBUILD so that it doesn't delete the .el.gz files. You don't need to patch Instead you need to make sure your main repo in "$startdir/emacs-git" is fully up to date. You can do this by running "git fetch --prune" in the directory. It should pull in the hook files if they are not in there already; if not, delete the repo and download again. Afterwards, you may need to delete your src directory and start afresh.

commented on 2014-12-01 11:34 (UTC)


commented on 2014-11-30 14:42 (UTC)


toropisco commented on 2014-11-17 14:14 (UTC)

@Pank, I may consider it if you ask nicely. "Why on earth would you do this:" makes me lose all respect of you.

Pank commented on 2014-11-16 19:48 (UTC)

Why on earth would you do this: # Delete compressed .el.gz files. Comment out if needed. find "$pkgdir"/usr/share/emacs/ -name "*.el.gz" -exec rm {} \; You break functionality of the online help.

toropisco commented on 2014-11-14 01:16 (UTC)

My apologies for the travel back in time but you may have already discovered that the final bzr to git conversion and transition weeded out about 20000 bogus comits.

toropisco commented on 2014-11-06 01:39 (UTC)

A quick heads up to the users of emacs-bzr. Emacs' source repository will switch to Git on November 11 and bzr will be out of the picture according to ESR[1] who did the actual repository conversion. You may want to start switching to the emacs-git package. Cheers. [1]

toropisco commented on 2014-10-10 23:13 (UTC)

@alexandernst Perhaps because you are using yaourt? ;-) It compiles fine here as of *now*. Joking aside (and the fact that yaourt is a poor way to handle your aur packages and a great way to hose your system, I'd sell you on packer and cower if I could), this is the development trunk; it can break and unbreak at any moment and when it happens you get to keep the pieces. Try again downloading the pkgbuild and using makepkg; you don't want to compile a package this big in RAM (that's what tmpfs is after all) unless you have at least 8GB RAM. The git repo is about 1.2G and add to that another 1G from source compile object, package binaries and packaging and compresson space.

alexandernst commented on 2014-10-10 16:30 (UTC)

I'm getting this: Finding pointers to doc strings... Finding pointers to doc strings...done Dumping under the name emacs /bin/sh: line 7: 7849 Segmentation fault (core dumped) ./temacs --batch --load loadup bootstrap Makefile:832: recipe for target 'bootstrap-emacs' failed make[1]: *** [bootstrap-emacs] Error 1 make[1]: Leaving directory '/tmp/yaourt-tmp-alexandernst/aur-emacs-git/src/emacs-git/src' Makefile:379: recipe for target 'src' failed make: *** [src] Error 2 Why is this happening?

thiagowfx commented on 2014-08-01 01:14 (UTC)

Please add missing dependency: libotf (from the 'extra' repository). Otherwise, one gets the following error after executing emacs: emacs: error while loading shared libraries: cannot open shared object file: No such file or directory

toropisco commented on 2014-06-21 14:06 (UTC)

It seems we may need to wait for a while. In the meantime, I've uploaded a PKGBUILD that includes the fixes already present in the stable branch. If you get patching failures, let me know and I'll drop the patch; it means the problem would be fixed already in trunk.

toropisco commented on 2014-06-19 17:48 (UTC)

As it is not needed anymore, I'm dropping the gist.

toropisco commented on 2014-06-19 17:43 (UTC)

@nicolasavru Good to know. It is just a matter of waiting for a few days I guess.

nicolasavru commented on 2014-06-19 17:34 (UTC)

I tried the emacs-24 branch and it has the same issue. The reporter of the bug [1] also reports the same results. The current assumption is that it is a bug with something in the toolchain (gcc/binutils mentioned) related to link time optimization [2]. Compiling without link time optimization does indeed fix it. As fir the giflib patch, it was already committed to the emacs-24 branch and should be merged into trunk soon. Conclusion: the emacs-24 branch currently compiles without link time optimization. trunk does not yet have the giflib patch, but it will probably also only compile without link time optimization. [1] [2]

toropisco commented on 2014-06-19 13:42 (UTC)

Make that $pkgname::git:// I am uploading the giflib patch as part of the PKGBUILD because there will be a fix integrated sometime soon. In the meantime I'll point you guys to this gist:

toropisco commented on 2014-06-19 13:34 (UTC)

@nicolassavru Thanks for the heads up! I have applied cleanly a patch based on the bug report but as you poing out, there are serious problems with gettext in trunk. For now I recommend to stay in whatever rev you are right now. If you are trying to compile emacs-git for the first time in your system be patient until trunk is unbroken, OR add "branch=emacs-24" to the git checkout line in sources as that will give you the stable maintenance tree. I could upload that as a new PKGBUILD. You wouldn't need to redownload your git repo but rather move it, copy it or link it with a different name. Let me know if you want that.

nicolasavru commented on 2014-06-19 01:57 (UTC)

The giflib bug should be fixed now: Unfortunately I cannot test that because there is another bug preventing emacs trunk from building currently. This bug seems to also affect Debian unstable and has already been reported [1][2], but a fix hasn't been proposed yet. [1] [2]

guotsuan commented on 2014-06-17 09:33 (UTC)

Hi, I tried to port the patch in emacs 24.3 in the extra repos to 24.4 emacs-git here. It works for me. Could you help test it and include it in the package if it is ok? Thanks. emacs-24.4-giflib5.patch ================================================================================ --- src/image.c +++ src/image.c @@ -7414,7 +7414,12 @@ gif_load (struct frame *f, struct image *img) if (!check_image_size (f, gif->SWidth, gif->SHeight)) { image_error ("Invalid image size (see `max-image-size')", Qnil, Qnil); +#if GIFLIB_MAJOR >=5 && GIFLIB_MINOR >=1 + fn_DGifCloseFile (gif, NULL); +#else fn_DGifCloseFile (gif); +#endif + return 0; } @@ -7423,7 +7428,11 @@ gif_load (struct frame *f, struct image *img) if (rc == GIF_ERROR || gif->ImageCount <= 0) { image_error ("Error reading `%s'", img->spec, Qnil); +#if GIFLIB_MAJOR >=5 && GIFLIB_MINOR >=1 + fn_DGifCloseFile (gif, NULL); +#else fn_DGifCloseFile (gif); +#endif return 0; } @@ -7435,7 +7444,12 @@ gif_load (struct frame *f, struct image *img) { image_error ("Invalid image number `%s' in image `%s'", image_number, img->spec); - fn_DGifCloseFile (gif); + +#if GIFLIB_MAJOR >=5 && GIFLIB_MINOR >=1 + fn_DGifCloseFile (gif, NULL); +#else + fn_DGifCloseFile (gif); +#endif return 0; } } @@ -7453,7 +7467,11 @@ gif_load (struct frame *f, struct image *img) if (!check_image_size (f, width, height)) { image_error ("Invalid image size (see `max-image-size')", Qnil, Qnil); +#if GIFLIB_MAJOR >=5 && GIFLIB_MINOR >=1 + fn_DGifCloseFile (gif, NULL); +#else fn_DGifCloseFile (gif); +#endif return 0; } @@ -7471,7 +7489,11 @@ gif_load (struct frame *f, struct image *img) && 0 <= subimg_left && subimg_left <= width - subimg_width)) { image_error ("Subimage does not fit in image", Qnil, Qnil); - fn_DGifCloseFile (gif); +#if GIFLIB_MAJOR >=5 && GIFLIB_MINOR >=1 + fn_DGifCloseFile (gif, NULL); +#else + fn_DGifCloseFile (gif); +#endif return 0; } } @@ -7479,7 +7501,11 @@ gif_load (struct frame *f, struct image *img) /* Create the X image and pixmap. */ if (!image_create_x_image_and_pixmap (f, img, width, height, 0, &ximg, 0)) { +#if GIFLIB_MAJOR >=5 && GIFLIB_MINOR >=1 + fn_DGifCloseFile (gif, NULL); +#else fn_DGifCloseFile (gif); +#endif return 0; } @@ -7650,7 +7676,11 @@ gif_load (struct frame *f, struct image *img) Fcons (make_number (gif->ImageCount), img->lisp_data)); - fn_DGifCloseFile (gif); +#if GIFLIB_MAJOR >=5 && GIFLIB_MINOR >=1 + fn_DGifCloseFile (gif, NULL); +#else + fn_DGifCloseFile (gif); +#endif /* Maybe fill in the background field while we have ximg handy. */ if (NILP (image_spec_value (img->spec, QCbackground, NULL)))

toropisco commented on 2014-06-16 15:34 (UTC)

Sooo, the fix for now is to add "--without-gif" to the compilation options. All who have working installations should stay with them for the time being.

toropisco commented on 2014-06-16 15:23 (UTC)

LTO has nothing to do with building failures. It has all to do with the new giflib library in Arch, which emacs cannot handle. I don't have time right now to port the fix applied to emacs 2.4.3 in the extra repos. If anyone has the time and beats me to it, I'll gladly include it in this PKGBUILD.

guotsuan commented on 2014-06-15 23:46 (UTC)

with the option --enable-link-time-optimization The building of the package failed. I'm wondering if anyone met the same questions too?

toropisco commented on 2014-03-29 18:44 (UTC)

@fizban007 Thanks for the heads up and fix.

fizban007 commented on 2014-03-29 15:49 (UTC)

The PKGBUILD has a problem with pkgver() function in the latest git pull. It reads "" instead of the correct string "24.4.50". Consider changing the regex to the following 's/^.\+\ \([0-9]\+\.[0-9]\+\.[0-9]\+\).\+$/\1/'

toropisco commented on 2014-03-26 21:15 (UTC)

@Earnest your arguments are sound and logic. Acted upon. I have no problem leaving this package in the hands of either of you. Just ask.

Earnest commented on 2014-03-26 16:20 (UTC)

holos is correct; this PKGBUILD needs to provide both a conflict and provide on just 'emacs' as does any other good emacs PKGBUILD on Arch. This means that packages looking for "emacs" as a dependency won't fail as your "emacs-git" will *provide* it. It should also conflict with 'emacs' as you install to the same locations which would cause real conflicts.

holos commented on 2014-03-26 16:19 (UTC)

bringing all this into one comment: your PKGBUILD should have both conflicts=('emacs') and provides=('emacs'). including all the other packages (which themselves should only have the conflicts/provides of emacs) is also incorrect. your communication style suggests you need to stop reading so far into suggestions.

GJdan commented on 2014-03-20 04:39 (UTC)

Forgot to add provides=('emacs') to PKGBUILD?

commented on 2014-03-13 09:42 (UTC)

@vorbote Ah, ok. Thanks for the comment.

commented on 2014-03-05 09:51 (UTC)

The dependencies look quite different form emacs-bzr at Can you comment?

nsantos commented on 2013-10-16 00:13 (UTC)

@ptrv Thanks for the heads up.

ptrv commented on 2013-10-10 11:03 (UTC)

The giflib5 patch can be removed. Emacs trunk revision 114602 fixed the issue.

sa1 commented on 2013-08-16 18:01 (UTC)

Yes, bzr is too slow. emacs-git should be revived. @artagnon please do so.

nsantos commented on 2013-08-04 12:44 (UTC)

Thanks for the fix, @ptrv. Elected not to use your changes directly (wanted to do some recipe cleanup, while I was at it), but I appreciate the heads up.

ptrv commented on 2013-08-02 09:06 (UTC)

I have updated the PKGBUILD to use new VCS source notation, updated the .install to match the one for emacs 24.3 from arch abs, and added new patch for giflib5 PKGBUILD: emacs-bzr-giflib5.patch: emacs-bzr.install:

jpkotta commented on 2013-04-08 17:03 (UTC)

The ImageMagick build error can be fixed by patching I posted a fix for emacs-lucid (; a similar one will certainly work here.

madalu commented on 2013-04-04 13:32 (UTC)

I can confirm this error with the ImageMagick update.

commented on 2013-03-29 01:43 (UTC)

When building I get a ton of imagemagick_errors such as undefined reference to `MagickGetException' Any idea. Was imagemagick updated to a version incompatible with this?

artagnon commented on 2013-03-08 14:41 (UTC)

bzr sucks: it's so horribly slow. Should I revive emacs-git and point it to the official Savannah mirror?

alucryd commented on 2013-02-18 10:53 (UTC)

No problem, thx for the explanation. Merging into emacs-bzr then.

commented on 2013-02-18 10:51 (UTC)

Hi, Sorry for my late reply. As the official Emacs repo, both bzr and git, was quite slow in China when I created this package, I use Github mirror instead. Now Emacs 24 has already in the official repo and I didn't use this package anymore. Please merge this into emacs-bzr. Sorry for the inconvenience.

alucryd commented on 2013-02-18 09:40 (UTC)

Hi, as fleet said, why are you using a mirror instead of the official git repo? Also, the bzr version of this package (emacs is hosted on git, bzr and cvs, all official repos) has been around longer than yours, and unless there is a reason you need to use git, I will be merging this into emacs-bzr.

eliasson commented on 2013-02-08 22:28 (UTC)

Actually, I believe I compiled emacs-bzr on one system that has these packages installed and then installed the package on another that didn't, expecting pacman to install all dependencies automatically. I didn't consider the fact that configure can enable/disable features based on which libraries are available.

nsantos commented on 2012-12-26 05:48 (UTC)

@eliasson Not sure why you're getting those errors, but configure should've figured out that you don't have those libs when you were building Emacs. I'm on x86_64 at the moment with no problems: # pacman -Qi m17n-lib imagemagick libotf error: package 'm17n-lib' was not found error: package 'imagemagick' was not found error: package 'libotf' was not found Maybe you built the package with those libs installed, then subsequently removed them?

eliasson commented on 2012-12-18 12:34 (UTC)

Please add imagemagick, libotf and m17n-lib to the depends. Reason: $ emacs emacs: error while loading shared libraries: cannot open shared object file: No such file or directory # pacman -S imagemagick $ emacs emacs: error while loading shared libraries: cannot open shared object file: No such file or directory # pacman -S libotf $ emacs emacs: error while loading shared libraries: cannot open shared object file: No such file or directory Using x86_64.

nsantos commented on 2012-11-10 12:24 (UTC)

@aurelien Weird issue. Maybe Savannah was down when you tried?

aurelien commented on 2012-11-06 07:55 (UTC)

trouble for me during the build. Stop after Connecting to Savannah Optional dependencies for bzr python2-paramiko: for sftp support ==> Retrieving Sources... ==> Extracting Sources... ==> Entering fakeroot environment... ==> Determining latest bzr revision... -> Version found: 110811 ==> Starting build()... ==> Connecting to Savannah...

nsantos commented on 2012-10-06 08:52 (UTC)

Put "make bootstrap" back in. This should fix most those intermittent build failures that mostly don't make sense, judging from the thrown error messages. This *won't*, however, facilitate building a package in those instances wherein the repo itself is in a broken state. Also added a new option _opt_puresize. Raised the default from about 1.68 megs to about 2 megs. (This isn't the final value; there're still other calculations applied to this to get the final value. See src/puresize.h for details.) This should help those who've encountered error messages regarding Pure Storage for Emacs Lisp, and noticed Emacs leaking like a sieve. If you've never had this error message pop up on you, don't worry about the increased memory--in my experience, it doesn't really add much of an overhead (am using a 6+ year old, 32-bit laptop with 2gigs of RAM). If you're truly concerned, you can just comment out the call-out to sed about halfway through the recipe.

nsantos commented on 2012-09-28 00:22 (UTC)

LOL, yeah. Fixed now.

commented on 2012-09-27 17:54 (UTC)

@nsantos: NP :-). You still have a little error in your PKGBUILD, regarding the dependency resolution: if [[ $_opt_use_gtk3 = "y" ]]; then depends=('dbus-core' 'desktop-file-utils' 'libpng' 'libtiff' 'librsvg' 'giflib' 'gtk3' 'libxpm' 'libjpeg>=7' 'hicolor-icon-theme') else depends=('dbus-core' 'desktop-file-utils' 'libpng' 'libtiff' 'librsvg' 'giflib' 'gtk2' 'libxpm' 'libjpeg>=7' 'hicolor-icon-theme') fi You should change the $_opt_use_gtk3 there to $_opt_use_gtk2 and exchange the gtk3 and gtk2 dependencies. Vale, Quintus

nsantos commented on 2012-09-25 07:40 (UTC)

@Quintus Thanks for the head's up. Since 3.x is now the default, I did just as you suggested.

commented on 2012-09-14 22:04 (UTC)

The PKGBUILD always builds the GTK3 version of emacs, this option is useless: # Don't compile against Gtk+ 3.x by default; stick with Gtk+ 2.x _opt_use_gtk3="n" To correct this, further down replace --with-x-toolkit=gtk with --with-x-toolkit=gtk2 Emacs now builds GTK3 by default if GTK2 is not requested specifically. Instead you could of course change the option to "_opt_use_gtk2" :-) Vale, Quintus

eschulte commented on 2012-07-30 18:07 (UTC)

WRT the conflicts, adding the following to the "cleaning up..." section of PKGBUILD allows me to sucessfully install this package, although I do get a "error: command failed to execute correctly" warning printed after instillation. rm /usr/share/info/ || return 1 I don't know if this is a desirable or general solution.

eschulte commented on 2012-07-30 16:03 (UTC)

I'm getting the following conflict when installing with pacman -U error: failed to commit transaction (conflicting files) emacs-bzr: /usr/share/info/ exists in filesystem Errors occurred, no packages were upgraded. I see this mentioned in the comments below, but see no solution posted. Thanks,

andrej84 commented on 2012-07-30 15:41 (UTC)

Sorry my bad, it was still an issue with the glibc upgrade, now after a correct upgrade and reboot everything works fine..

andrej84 commented on 2012-07-27 13:42 (UTC)

Not working here, and I get the same issue compiling by hand.. Actually gtk2 and 3 are there, but they are not found for some reasons.. any idea? checking for gtk_main... no configure: error: Gtk+ wanted, but it does not compile, see config.log. Maybe some x11-devel files missing?

commented on 2012-06-02 22:01 (UTC)

An additional make worked for me, too: I noticed it was building in src/emacs-build, so that's where I did the make. Then, I went back to the directory with the PKGBUILD and ran 'makepkg -s' again. Regards

fleet commented on 2012-06-02 13:06 (UTC)

It might be a stupid question, but why are you using a GitHub mirror and not git://

sa1 commented on 2012-05-31 18:58 (UTC)

@hanjianwei Right, that was pacaur's fault. I did it with cower and it built fine.

nsantos commented on 2012-05-31 02:41 (UTC)

rev 108433 sort of worked for me; had to put in an additional 'make' before 'make install' for some reason, though. Before I did that, makepkg died as though it encountered an error (but going into src/emacs-build and running make worked fine.

fgr commented on 2012-05-30 18:12 (UTC)

I've just compiled the latest revision (108430). There are no errors.

nsantos commented on 2012-05-28 20:42 (UTC)

I get this: In toplevel form: emacs-lisp/easy-mmode.el:459:1:Error: Invalid byte code in /var/abs/local/emacs-bzr/src/emacs-build/lisp/emacs-lisp/cl-macs.elc make[2]: *** [emacs-lisp/easy-mmode.elc] Error 1 make[2]: *** Waiting for unfinished jobs.... Wrote /var/abs/local/emacs-bzr/src/emacs-build/lisp/emacs-lisp/edebug.elc make[2]: Leaving directory `/var/abs/local/emacs-bzr/src/emacs-build/lisp' make[1]: *** [compile-main] Error 2 make[1]: Leaving directory `/var/abs/local/emacs-bzr/src/emacs-build/lisp' make: *** [lisp] Error 2 with MAKEFLAGS set to "-j2". No clue what's going on, though.

fgr commented on 2012-05-27 07:39 (UTC)

@coroa: the same thing here.

commented on 2012-05-25 07:56 (UTC)

@squeegee Thank you very much! I have fixed it. I put this PKGBUILD on github: Fork and patch it at your convenience :) @sal Sorry for you inconvenience. I removed my Emacs and reinstalled it successfully with this PKGBUILD. BTW: I'm using yaourt.

sa1 commented on 2012-05-24 19:43 (UTC)

Fails to build.

commented on 2012-05-21 11:16 (UTC)

@Coroa, yeah me too, it seem to break with makeflags > 1

commented on 2012-05-21 11:12 (UTC)

for some days now building emacs fails for me (revision 108144 was the last one i built successfully) with /bin/sh: line 1: ../src/emacs: No such file or directory make[1]: *** [leim-list.el] Error 127 make[1]: Leaving directory `/tmp/emacs/emacs-bzr/src/emacs-build/leim' make: *** [install-leim] Error 2 i found that using make DESTDIR=${pkgdir} -j1 install seems to avoid the issue, so it's likely some upstream dependency issues (i've got MAKEFLAGS="-j3" in makepkg.conf). i'm just wondering if i'm the only one experiencing this problem and whether anyone knows something more about it.

nsantos commented on 2012-05-16 08:22 (UTC)

Generated info files were renamed in a recent merge; previously, Emacs' info files ended up as just <x>.gz so the conflict went unnoticed. When the generated files were re-targeted to <x>.info.gz, the problem reared its head. desktop-file-utils are now included in the requires= line (thanks, jongrocho).

commented on 2012-05-16 06:00 (UTC)

Dependency on 'desktop-file-utils' should be added to this package.

commented on 2012-05-14 19:02 (UTC)

The PKGBUILD needs a "cd .." before the else on line 37 (if you are rebuilding, it's in the emacs directory already, so need to go up one level).

kkl2401 commented on 2012-05-07 18:47 (UTC)

For a couple of days now, the package creates the file /usr/share/info/ which then conflicts with texinfo package.

nsantos commented on 2012-05-05 04:24 (UTC)

I think that, at this point--unless you *absolutely* have to have it--I recommend that emacs-bzr be compiled *without* ImageMagick support. I'd likely look into what the problem is, and (if I do) definitely file a bug report upstream if it's the Emacs devs that are screwing up. Except I've quite a bit on my plate at the moment.

donpicoro commented on 2012-05-03 23:24 (UTC)

I am not sure why you guys have problems compiling this package. I was using the GIT one and suddenly today it started complaining about assoc being obsolete so I compiled this one and it was perfectly fine. emacs-bzr 108116-1 The 'assoc' being obsolete still puzzles me though. Let me know if I can provide you with a list of installed packages or anything in order for you to succeed compiling this. Note: I am not using [testing]

ngz commented on 2012-05-03 13:38 (UTC)

I still encounter the problem reported by myuhe and I don't follow [testing] either.

nsantos commented on 2012-04-27 16:05 (UTC)

@bintang Ah! I believe you've hit the problem on its head. :P Nope, I don't follow [testing]; at least, not since I broke my main machine with it, with an important deadline looming. :P

commented on 2012-04-27 08:11 (UTC)

rev 108055 + gtk3 still fail :( @nsantos, do you use testing repo?

nsantos commented on 2012-04-24 14:13 (UTC)

@bintang, @myuhe I was able to build a package without problems. I'm at revision 108018, and am linking against GTK+3.

commented on 2012-04-24 09:23 (UTC)

Yup I can confirm myuhe error and I'm glad that i'm not alone. ~_~

nsantos commented on 2012-04-22 13:34 (UTC)

@myuhe Which version of GTK+ are you building against? (If you didn't edit the PKGBUILD, you built against version 2.x) I'd like to try and reproduce the error. (Also, sometimes, there are build errors that result from erroneous assumptions in the build environment in a particular revision. Either that, or it's just your garden-variety developer-induced bug. I've ran into a number of them while following -bzr; they usually go away after a few days or so (one time, an error got fixed by the very next commit). That's the price we pay for living on the edge. :D)

myuhe commented on 2012-04-22 10:19 (UTC)

I get the follow error. I couldn't solve it. anyone can solve it?

nsantos commented on 2012-02-09 19:59 (UTC)

Oh, hey, mrz beat me to it. :P

nsantos commented on 2012-02-09 19:59 (UTC)

@smoge return removed. As for the usage of chmod: its targets are all paths installed by Emacs' Makefile; they only need their permissions tweaked a bit. I've never used install for this purpose; is this a valid use case for it? @galdor Unless autoconf and automake have been moved out of the base-devel group, then, no, makedepends shouldn't include them. (This from

mrz commented on 2012-02-09 11:17 (UTC)

From the page "Base package groups" in the wiki:"The group "base-devel" is assumed to be installed when building with makepkg.". So autoconf and automake aren't needed in makedepends.

galdor commented on 2012-01-22 19:20 (UTC)

makedepends should include autoconf and automake.

nsantos commented on 2011-12-01 08:06 (UTC)

There's a bug in recent revisions (I'm up to 106565 at the moment) wherein Emacs insists on using Courier New as the default font, no matter what I set it to using custom. Current solution is to slap on a '(set-default-font "Liberation Mono-12")' line on top of your .emacs (it doesn't have to match your custom settings; it's just there to slap Emacs into conforming).

nsantos commented on 2011-11-02 18:41 (UTC)

@tigrmesh Was able to compile cleanly (am up to rev 106271); did you link against GTK3 or GTK2? I did fix the provides= line, though (used single-quotes instead of double-quotes), but I'm going to hold off uploading a new version of the PKGBUILD until we can figure out what went wrong with your build. Could you try rebuilding? Maybe it was a bug with the revision you tried to build? Thanks!

tigrmesh commented on 2011-11-01 03:04 (UTC)

I had a compile error, part of which was: fns.c: In function ‘secure_hash’: fns.c:4762:21: error: ‘MD5_DIGEST_SIZE’ undeclared (first use in this function) Thanks to falconindy, I was able to get this to compile by adding CPPFLAGS=-DMD5_DIGEST_SIZE=16 to the configure line, like so: ./ && CPPFLAGS=-DMD5_DIGEST_SIZE=16 ./configure --prefix=/usr \ Also, I'd like to suggest that the provides line be changed to: provides=(emacs) The current version shows this when I do pacman -Qi emacs-bzr Provides : emacs=$pkgver

nsantos commented on 2011-09-13 03:11 (UTC)

I added a flag that needs to be set manually before building, rather than relying on whether or not GTK+3 is installed. The default is to build with (and require) GTK+2, and will stay that way until GTK+3 displaces GTK+2.

paradoxxxzero commented on 2011-09-06 09:57 (UTC)

It might be a good idea to compile with --with-x-toolkit=gtk3 if gtk3 is installed.

nsantos commented on 2011-03-22 09:30 (UTC)

@dolby To be fair, the size more than doubles, since I duplicate the bzr checkout when building. Although, I could probably just hardlink everything from the actual checkout to reduce disk usage. More trouble than it's worth, though, IMO.

commented on 2011-03-22 08:49 (UTC)

Thanks for the reply. git with --depth 1 is 294mb in case you were wondering. Still much bigger than bzr though.

nsantos commented on 2011-03-22 08:29 (UTC)

@dolby The main gripe I have with bzr is how *slow* everything is. It's not because bzr is in Python; hg is rather quick. However, my laptop doesn't have much disk space (it's a little old), so I'm kind of okay trading speed for lower disk requirements.

nsantos commented on 2011-03-22 08:26 (UTC)

@dolby Right now, it's at 118 megs. Its been about a week since my last build, but I doubt it'd grow dramatically when I rebuild with the 'fix' for the issue @jxy noted.

commented on 2011-03-22 04:08 (UTC)

Can someone please tell me how big the dir in src/emacs gets using this script? I have a git tree here and its more than 800mb now. I know i could use --depth 1 with git, which seems to be equivalent to the --lightweight checkout option of bzr this script uses, to make it smaller, but they seem to have the same disadvages. I was wondering how big your bzr src/emacs dir is.

commented on 2011-03-21 20:04 (UTC)

There is no "configure" script in the bzr repo, now. Running is required to generate the file "configure".

nsantos commented on 2011-01-22 10:42 (UTC)

Why was this flagged out of date? Also, I forgot to note that the gcc-4.5 fix has already been taken out. So if that's the reason, can we un-flag this now? :P

commented on 2010-12-05 04:43 (UTC)

I believe you can now take the gcc-4.5 fix out of PKGBUILD.

tavianator commented on 2010-07-12 05:49 (UTC)

Yes indeed (I believe -2 pulled in the fix). However, the configure script stupidly checks gcc --version, instead of testing for the actual bug (which is easy; see the testcase attached to the GCC bug, or the two committed). So you'll have to either keep the workaround or patch ./configure.

nsantos commented on 2010-07-11 04:56 (UTC)

@tavianator You mean gcc-4.5.0-6 in core? If so, I'll take out the workaround later today.

tavianator commented on 2010-07-10 16:12 (UTC)

The bug reported below (which I actually reported) is fixed in Arch's latest gcc-4.5.0 snapshot.

nsantos commented on 2010-07-07 13:02 (UTC)

Fixed path names in clean up, removed unnecessary gzip'ping of info files in PKGBUILD.

roy_hu commented on 2010-07-07 06:58 (UTC)

info and man pages are already gzip'ed. Please fix them.

nsantos commented on 2010-05-19 04:07 (UTC)

Took out the md5sum line for the install script, plus added CFLAGS line as recommended.

commented on 2010-05-03 15:51 (UTC)

Configure scripts complains about gcc-4.5.0. """ configure: error: GCC 4.5.0 has problems compiling Emacs; see etc/PROBLEMS'. """ And in the file 'etc/PROBLEMS': ** Emacs crashes when running in a terminal, if compiled with GCC 4.5.0 This version of GCC is buggy: see You can work around this error in gcc-4.5 by omitting sibling call optimization. To do this, configure Emacs with CFLAGS="-g -O2 -fno-optimize-sibling-calls" ./configure