Summary: | [Tracker] Packages containing broken configure tests for Emacs | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Fernando (likewhoa) <email> |
Component: | Current packages | Assignee: | Emacs project <emacs> |
Status: | RESOLVED FIXED | ||
Severity: | normal | Keywords: | Tracker |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 335896, 335900, 335902, 336117, 336708, 336717, 336724, 336727, 336731, 336739, 336746 | ||
Bug Blocks: | |||
Attachments: |
config.log for app-shells/bash-4.0_p37
config.log for sys-libs/gpm-1.20.6 detailed config.log for gpm 'bash -x' output detailed configure output for gpm Packages calling emacs at build time in spite of USE="-emacs" |
Description
Fernando (likewhoa)
2010-09-03 22:34:01 UTC
*** Bug 335900 has been marked as a duplicate of this bug. *** need config.log (and no need to file multiple bugs on the same issue, like bug 335896) *** Bug 335902 has been marked as a duplicate of this bug. *** *** Bug 335896 has been marked as a duplicate of this bug. *** Created attachment 245903 [details]
config.log for app-shells/bash-4.0_p37
Created attachment 245904 [details]
config.log for sys-libs/gpm-1.20.6
if you need additional config.log for the rest of the packages that become frozen let me know. config.log attached guess: is /bin/sh pointing to something else than bash? Created attachment 245906 [details]
detailed config.log for gpm 'bash -x' output
Created attachment 245908 [details]
detailed configure output for gpm
just to follow up. /bin/sh points to /bin/bash. I have tried without emacs package without success. any other suggestions? this needs to be removed, pkg_postinst() { if use livecd; then [ -e "${EROOT}"/usr/bin/emacs ] || ln -s zile "${EROOT}"/usr/bin/emacs fi } it breaks building an actual livecd (which the original reporter is trying here) See bug 100286. To add an explanation why I won't remove pkg_postinst from the zile ebuild: /usr/bin/emacs is an eselectable symlink. Nothing prevents a user from linking it to a microemacs variant like /usr/bin/zile, /usr/bin/qemacs, or /usr/bin/me. Therefore packages' configure scripts shouldn't assume that /usr/bin/emacs is GNU Emacs, and especially shouldn't break if it isn't. Besides, they shouldn't even try to automatically detect lispdir, but explicitly set it with configure option --with-lispdir="${SITELISP}/${PN}" (where SITELISP is defined in elisp-common.eclass). In cases like bash that don't even install any Lisp files, configure --without-lispdir should be used. Reusing this bug as a tracker. There are 95 packages with the 'emacs' USE flag that could be affected by this, I will gather a list and attach fixes where needed, but just using --with-lispdir=${SITELISP}/${PN}" does not always work. I found sys-app/qingy as an example, that package will hang with default flags which are "econf --disable-emacs" unless you imply --without-lispdir. Please leave this bug open. (In reply to comment #17) > There are 95 packages with the 'emacs' USE flag that could be affected by this, > I will gather a list and attach fixes where needed, but just using > --with-lispdir=${SITELISP}/${PN}" does not always work. The USE="emacs" case shouldn't normally be a problem, because it will pull GNU Emacs as dependency, and then /usr/bin/emacs should point to it. What must be checked is packages' behaviour with USE="-emacs" and /usr/bin/emacs pointing to zile (or to another microemacs variant). Created attachment 246658 [details]
Packages calling emacs at build time in spite of USE="-emacs"
I've scanned all packages in system,all packages with an emacs USE flag, and a few others that are dependencies of them. In addition to the ones already mentioned, the following packages are problematic:
dev-lang/gforth-0.7.0
dev-scheme/bigloo-3.0c_p4
dev-util/desktop-file-utils-0.16
dev-util/global-5.9
dev-util/idutils-4.2
sci-mathematics/agda-1.0.2-r2
sci-mathematics/maxima-5.18.1
sci-mathematics/pari-2.3.4-r1
A log file with the arguments passed to emacs in each case is attached.
All done, therefore closing. Thank you for reporting this bug. |