Compilation of the latest emacs-vcs fails on the ./configure step, claiming that "You do not seem to have makeinfo >= 4.6". This message is, however, a red herring. The real error appears to be that the EGREP variable is not set by configure, and the makeinfo test fails when it tries to use egrep. In an earlier step, configure also reports the non-fatal error: "gl_EARLY: command not found". I'm not sure if this is also due to the empty EGREP. Reproducible: Always Steps to Reproduce: 1. cave resolve emacs-vcs -x Actual Results: >>> Starting src_configure * Configuring to build with GIMP Toolkit (GTK+) econf: updating /var/tmp/paludis/app-editors-emacs-vcs-24.0.9999/work/emacs-vcs-24.0.9999/config.guess with /usr/share/gnuconfig/config.guess econf: updating /var/tmp/paludis/app-editors-emacs-vcs-24.0.9999/work/emacs-vcs-24.0.9999/config.sub with /usr/share/gnuconfig/config.sub ./configure --prefix=/usr --host=i686-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --program-suffix=-emacs-24 --infodir=/usr/share/info/emacs-24 --with-crt-dir=/usr/lib --with-gameuser=games --without-compress-info --without-sound --with-x --without-gconf --without-xml2 --with-toolkit-scroll-bars --without-gif --without-jpeg --with-png --with-rsvg --without-tiff --with-xpm --without-imagemagick --with-xft --without-libotf --without-m17n-flt --with-x-toolkit=gtk --without-hesiod --without-kerberos --without-kerberos5 --with-gpm --with-dbus --without-gnutls --without-selinux --build=i686-pc-linux-gnu checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking for i686-pc-linux-gnu-gcc... i686-pc-linux-gnu-gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether i686-pc-linux-gnu-gcc accepts -g... yes checking for i686-pc-linux-gnu-gcc option to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of i686-pc-linux-gnu-gcc... gcc3 checking whether i686-pc-linux-gnu-gcc and cc understand -c and -o together... yes checking whether gcc understands -Wno-pointer-sign... yes checking whether gcc understands -Wdeclaration-after-statement... ./configure: line 5053: gl_EARLY: command not found yes checking whether gcc understands -Wold-style-definition... yes checking whether gcc understands -Wimplicit-function-declaration... yes checking how to run the C preprocessor... i686-pc-linux-gnu-gcc -E checking for i686-pc-linux-gnu-ranlib... i686-pc-linux-gnu-ranlib checking for install-info... /usr/bin/install-info checking for install-info... (cached) /usr/bin/install-info checking for install-info... (cached) /usr/bin/install-info checking for gzip... /bin/gzip checking for makeinfo... /usr/bin/makeinfo ./configure: line 5971: texinfo[^0-9]*([1-4][0-9]+|[5-9]|4\.[6-9]|4\.[1-5][0-9]+): command not found configure: error: You do not seem to have makeinfo >= 4.6, and your source tree does not seem to have pre-built manuals in the `info' directory. Either install a suitable version of makeinfo, or re-run configure with the `--without-makeinfo' option to build without the manuals. Expected Results: emacs-vcs should configure and compile successfully. Use flags USE (X) (-Xaw3d) (alsa) (dbus) (-gconf) (-gif) (-gnutls) (gpm) (gtk) (gzip-el) (-hesiod) (-imagemagick) (-jpeg) (-kerberos) (-libxml2) (-m17n-lib) (-motif) (png) (-selinux) (-sound) (source) (svg) (-tiff) (toolkit-scroll-bars) (xft) (xpm)
Compilation of the live ebuild fails since about two days. This kind of bugs is best handled upstream, because there's not much that we could do about this at the distro level. As a remedy, I had already added app-editors/emacs-vcs-24.0.50_pre20110116 which is a snapshot of the upstream BZR repo from before the gnulib merge.
Actually, it turned out that there is a simple workaround. I've added an additional AT_M4DIR=m4 to eautoreconf. It should be fixed now; feel free to reopen if any problems remain.
Ulrich - thanks for your impressively rapid response. Also, sorry for not spotting the emacs-vcs-24.0.50_pre20110116 snapshot which you had the foresight to provide, I should have seen it and tried it first. I have now, and it compiles and runs cleanly. With your eautoreconf fix, I can confirm that the configure step now succeeds. But compilation now fails with the following: [...] In toplevel form: org-clock.el:1583:1:Warning: global/dynamic var `state' lacks a prefix Loading /var/tmp/paludis/app-editors-emacs-vcs-24.0.9999/work/emacs-vcs-24.0.9999/lisp/emacs-lisp/cl-extra.el (source)... Compiling org/org-compat.el Wrote /var/tmp/paludis/app-editors-emacs-vcs-24.0.9999/work/emacs-vcs-24.0.9999/lisp/org/org-clock.elc Compiling org/org-complete.el Wrote /var/tmp/paludis/app-editors-emacs-vcs-24.0.9999/work/emacs-vcs-24.0.9999/lisp/org/org-compat.elc Compiling org/org-crypt.el Wrote /var/tmp/paludis/app-editors-emacs-vcs-24.0.9999/work/emacs-vcs-24.0.9999/lisp/org/org-complete.elc make[3]: *** [org/org-colview.elc] Segmentation fault make[3]: *** Waiting for unfinished jobs.... I'm not reopening though, since presumably this is an upstream problem which is par for the course when using a live ebuild. Give it a few days and I expect upstream will have fixed emacs in bzr so it compiles again. BTW, should I be reporting this kind of breakage to emacs-devel or to bug.gentoo.org in the future?
(In reply to comment #3) > BTW, should I be reporting this kind of breakage to emacs-devel or to > bug.gentoo.org in the future? You have to use you own judgement. If it's clearly an upstream issue, you should report it to emacs-devel. If not, or when in doubt, report it here.
(In reply to comment #3) > BTW, should I be reporting this kind of breakage to emacs-devel or to > bug.gentoo.org in the future? As a guideline: If it is a widespread configuration option that causes the failure you can just wait, if it is something exotic (kerberos e.g.) or on a strange processor architecture you should definitely report it. We appreciate a direct report to upstream, but we provide a pass-through service and handle upstream. We have some experience with upstream though Ulrich's reports get neglected more often because of dark matter issues. :)
