Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 136220 - emacs ebuild prepends portage path to lisp vars
Summary: emacs ebuild prepends portage path to lisp vars
Status: RESOLVED NEEDINFO
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: Sparc Linux
: High normal (vote)
Assignee: Emacs project
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-06-09 12:39 UTC by Alex Deucher
Modified: 2007-04-22 22:30 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
config.status (config.status,36.29 KB, text/plain)
2007-02-26 16:24 UTC, Alex Deucher
Details
epaths.h (epaths.h,2.62 KB, text/plain)
2007-02-26 16:25 UTC, Alex Deucher
Details
build.log (build.log,129.48 KB, text/plain)
2007-02-28 15:04 UTC, Alex Deucher
Details
new epaths.h (epaths.h,3.00 KB, text/plain)
2007-02-28 18:13 UTC, Alex Deucher
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Deucher 2006-06-09 12:39:47 UTC
after an emerge update, I get the following warnings when starting emacs, and none of the emacs modules work.

Warning: arch-dependent data dir (/var/tmp/portage/emacs-21.4-r3/image//usr/libexec/emacs/21.4/sparc-unknown-linux-gnu/) does not exist.
Warning: arch-independent data dir (/var/tmp/portage/emacs-21.4-r3/image//usr/share/emacs/21.4/etc/) does not exist.
Warning: Lisp directory `/var/tmp/portage/emacs-21.4-r3/image//usr/share/emacs/21.4/site-lisp' does not exist.
Warning: Lisp directory `/var/tmp/portage/emacs-21.4-r3/image//usr/share/emacs/site-lisp' does not exist.
Warning: Lisp directory `/var/tmp/portage/emacs-21.4-r3/image//usr/share/emacs/21.4/leim' does not exist.
Warning: Lisp directory `/var/tmp/portage/emacs-21.4-r3/image//usr/share/emacs/21.4/lisp' does not exist.

This is an smp sprac64 box. make.conf:
# These settings were set by the catalyst build script that automatically built this stage
# Please consult /etc/make.conf.example for a more detailed example
#CFLAGS="-O2 -mcpu=ultrasparc"
CFLAGS="-mcpu=ultrasparc -O3 -pipe"
CHOST="sparc-unknown-linux-gnu"

#CXXFLAGS="-O2 -mcpu=ultrasparc"
CXXFLAGS="-mcpu=ultrasparc -O3 -pipe"
MAKEOPTS="-j5"
USE="-X zlib png crypt"

# GENTOO_MIRRORS="ftp:///ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ ftp://ftp6.uni-erlangen.de/pub/mirrors/gentoo ftp://vlaai.snt.ipv6.utwente.nl/pub/os/linux/gentoo/ http://ftp6.uni-erlangen.de/pub/mirrors/gentoo ftp://mirror.nutsmaas.nl/gentoo/"
#GENTOO_MIRRORS="http://gentoo.osuosl.org/
GENTOO_MIRRORS="http://gentoo.mirrors.pair.com/ ftp://ftp.gtlib.cc.gatech.edu/pub/gentoo"


# emerge --info emacs
Portage 2.0.54-r2 (default-linux/sparc/sparc64/2006.0/2.4, gcc-3.3.5-20050130, glibc-2.3.6-r3, 2.4.29-sparc sparc64)
=================================================================
System uname: 2.4.29-sparc sparc64 sun4u
Gentoo Base System version 1.6.14
dev-lang/python:     2.3.5, 2.4.2
dev-python/pycrypto: [Not Present]
dev-util/ccache:     [Not Present]
dev-util/confcache:  [Not Present]
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.59-r7
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1
sys-devel/binutils:  2.16.1-r2
sys-devel/gcc-config: 1.3.13-r2
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.4.26-r1
ACCEPT_KEYWORDS="sparc"
AUTOCLEAN="yes"
CBUILD="sparc-unknown-linux-gnu"
CFLAGS="-mcpu=ultrasparc -O3 -pipe"
CHOST="sparc-unknown-linux-gnu"
CONFIG_PROTECT="/etc /usr/lib/X11/xkb /var/bind"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-mcpu=ultrasparc -O3 -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig distlocks sandbox sfperms strict"
GENTOO_MIRRORS="http://gentoo.mirrors.pair.com/ ftp://ftp.gtlib.cc.gatech.edu/pub/gentoo"
MAKEOPTS="-j5"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="sparc apache2 arts avi berkdb bitmap-fonts bzip2 cli crypt cups dba dlloader dri eds encode esd expat fbcon foomaticdb fortran gcc64 gd gdbm gif gnome gstreamer gtk gtk2 imlib isdnlog jpeg kde libwww mad mhash mikmod motif mpeg ncurses nls ogg opengl oss pam pcre pdflib perl png postgres pppd python qt readline reflection sdl session slang spell spl ssl tcpd tiff truetype truetype-fonts type1-fonts vorbis xml xml2 xmms xorg xv zlib userland_GNU kernel_linux elibc_glibc"
Unset:  CTARGET, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_RSYNC_EXTRA_OPTS, PORTAGE_RSYNC_OPTS, PORTDIR_OVERLAY
Comment 1 Matthew Kennedy (RETIRED) gentoo-dev 2006-06-11 08:46:07 UTC
Is it possible your bug is also Bug #22563?
Comment 2 Alex Deucher 2006-06-11 10:43:53 UTC
(In reply to comment #1)
> Is it possible your bug is also Bug #22563?
> 

It looks very similar.  however, the embedded portage paths seem more pervasive in my case, as I cannot even save files since emacs cannot find the modules it needs to do that due to the bad paths.
Comment 3 Christian Faulhammer (RETIRED) gentoo-dev 2007-02-23 07:45:19 UTC
Alex, does the problem persist with the latest version of 21.4-r7 and/or emacs-cvs?
Comment 4 Alex Deucher 2007-02-23 20:13:26 UTC
(In reply to comment #3)
> Alex, does the problem persist with the latest version of 21.4-r7 and/or
> emacs-cvs?
> 

21.4-r7 still has the problem.  I'm not sure how to get the cvs version.  Or do you mean on of the 22 pre versions?
Comment 5 Ulrich Müller gentoo-dev 2007-02-23 21:43:19 UTC
What is very strange is that the .../image path names appear. The build process dumps the Emacs executable while running in the .../work/emacs-21.4 directory, so I am pretty sure that this issue is different from bug #22563.

Alex: Could you do an "ebuild emacs-21.4-r7.ebuild compile" and post the resulting files "config.status" and "src/epaths.h" (in /var/tmp/portage/app-editors/emacs-21.4-r7/work/emacs-21.4) here?
Comment 6 Alex Deucher 2007-02-23 23:04:10 UTC
(In reply to comment #5)
> What is very strange is that the .../image path names appear. The build process
> dumps the Emacs executable while running in the .../work/emacs-21.4 directory,
> so I am pretty sure that this issue is different from bug #22563.
> 
> Alex: Could you do an "ebuild emacs-21.4-r7.ebuild compile" and post the
> resulting files "config.status" and "src/epaths.h" (in
> /var/tmp/portage/app-editors/emacs-21.4-r7/work/emacs-21.4) here?
> 

I get the following failure:

 # ebuild emacs-21.4-r7.ebuild compile
Traceback (most recent call last):
  File "/usr/sbin/ebuild", line 138, in ?
    debug=debug, tree=mytree)
  File "/usr/lib/portage/pym/portage.py", line 3537, in doebuild
    newuris, alist = mydbapi.getfetchlist(
AttributeError: vardbapi instance has no attribute 'getfetchlist'

Comment 7 Christian Faulhammer (RETIRED) gentoo-dev 2007-02-24 10:05:49 UTC
(In reply to comment #6)
>  # ebuild emacs-21.4-r7.ebuild compile

 You did that in the ebuild's directory?
Comment 8 Alex Deucher 2007-02-26 16:03:27 UTC
(In reply to comment #7)
> (In reply to comment #6)
> >  # ebuild emacs-21.4-r7.ebuild compile
> 
>  You did that in the ebuild's directory?
> 

yes:
/var/db/pkg/app-editors/emacs-21.4-r7
seems to be where the ebuild is.
Comment 9 Christian Faulhammer (RETIRED) gentoo-dev 2007-02-26 16:06:08 UTC
(In reply to comment #8)
> (In reply to comment #7)
> > (In reply to comment #6)
> > >  # ebuild emacs-21.4-r7.ebuild compile
> >  You did that in the ebuild's directory?
> yes:
> /var/db/pkg/app-editors/emacs-21.4-r7
> seems to be where the ebuild is.

 Hmmm, you should try /usr/portage/app-editors/emacs/.
Comment 10 Alex Deucher 2007-02-26 16:24:49 UTC
Created attachment 111315 [details]
config.status
Comment 11 Alex Deucher 2007-02-26 16:25:12 UTC
Created attachment 111316 [details]
epaths.h
Comment 12 Ulrich Müller gentoo-dev 2007-02-26 17:14:16 UTC
Your config.status and epaths.h look O.K. to me, /var/tmp/portage appears only at places where it should.

What are the values of "exec-directory", "data-directory", and "load-path" within Emacs? (Start emacs, then do "C-h v exec-directory <RET>" etc.)

Are these values the same when you start Emacs with "emacs -q -no-site-file"?
Comment 13 Alex Deucher 2007-02-27 19:05:33 UTC
(In reply to comment #12)
> Your config.status and epaths.h look O.K. to me, /var/tmp/portage appears only
> at places where it should.
> 
> What are the values of "exec-directory", "data-directory", and "load-path"
> within Emacs? (Start emacs, then do "C-h v exec-directory <RET>" etc.)
> 

All of them produce this message:
Cannot open load file: view

C-h ? produces this message:
Cannot open doc string file "/var/tmp/portage/app-editors/emacs-21.4-r7/image//usr/share/emacs/21.4/etc/DOC-21.4.3"

> Are these values the same when you start Emacs with "emacs -q -no-site-file"?
> 

Same behavior as above.
Comment 14 Ulrich Müller gentoo-dev 2007-02-27 19:28:31 UTC
(In reply to comment #13)
> > What are the values of "exec-directory", "data-directory", and "load-path"
> > within Emacs? (Start emacs, then do "C-h v exec-directory <RET>" etc.)
> 
> All of them produce this message:
> Cannot open load file: view

Oops. Please try the following, then:
- Start emacs and type "exec-directory C-j" (in the *scratch* buffer)
- Start emacs, then do "M-: exec-directory <RET>"
I hope at least one of them will function. :-/
Comment 15 Alex Deucher 2007-02-27 19:53:53 UTC
(In reply to comment #14)
> (In reply to comment #13)
> > > What are the values of "exec-directory", "data-directory", and "load-path"
> > > within Emacs? (Start emacs, then do "C-h v exec-directory <RET>" etc.)
> > 
> > All of them produce this message:
> > Cannot open load file: view
> 
> Oops. Please try the following, then:
> - Start emacs and type "exec-directory C-j" (in the *scratch* buffer)
> - Start emacs, then do "M-: exec-directory <RET>"
> I hope at least one of them will function. :-/
> 

I assume you want all of this in the same emacs session.  Here's the result:
"/var/tmp/portage/app-editors/emacs-21.4-r7/image//usr/libexec/emacs/21.4/sparc-unknown-linux-gnu/"
Comment 16 Ulrich Müller gentoo-dev 2007-02-27 23:02:45 UTC
This is all very strange.

- The build process (up to and including src_compile) does not make use
  of the image ("${D}") directory. Also, the path definitions in epaths.h
  appear to be right.

- During runtime, Emacs also shouldn't have information about Portage's
  intermediate install (image) directory.

- This leaves src_install() as a candidate where the problem could be.
  The double slashes in your lisp variables could be a telltale sign (since
  ${D} ends with a slash and is prepended to a path starting with one).
  OTOH, I cannot imagine how the Emacs executable could be changed during
  the installation phase.

Could you run "ebuild /usr/portage/app-editors/emacs/emacs-21.4-r7.ebuild install" again and attach the complete build.log file? You find it in /var/tmp/portage/app-editors/emacs-21.4-r7/temp .

The standard Emacs directories (e.g. /usr/share/emacs/21.4/etc and /usr/share/emacs/21.4/lisp) do exist after installation?
Comment 17 Alex Deucher 2007-02-28 15:01:56 UTC
(In reply to comment #16)
> This is all very strange.
> 
> - The build process (up to and including src_compile) does not make use
>   of the image ("${D}") directory. Also, the path definitions in epaths.h
>   appear to be right.
> 
> - During runtime, Emacs also shouldn't have information about Portage's
>   intermediate install (image) directory.
> 
> - This leaves src_install() as a candidate where the problem could be.
>   The double slashes in your lisp variables could be a telltale sign (since
>   ${D} ends with a slash and is prepended to a path starting with one).
>   OTOH, I cannot imagine how the Emacs executable could be changed during
>   the installation phase.
> 
> Could you run "ebuild /usr/portage/app-editors/emacs/emacs-21.4-r7.ebuild
> install" again and attach the complete build.log file? You find it in
> /var/tmp/portage/app-editors/emacs-21.4-r7/temp .

Very strange... doing that seems to have fixed emacs.  I no longer get the directory errors.

> 
> The standard Emacs directories (e.g. /usr/share/emacs/21.4/etc and
> /usr/share/emacs/21.4/lisp) do exist after installation?
> 

yes.  they exist.
Comment 18 Alex Deucher 2007-02-28 15:04:28 UTC
Created attachment 111565 [details]
build.log
Comment 19 Ulrich Müller gentoo-dev 2007-02-28 15:45:42 UTC
Hmm, at the beginning of the Install phase (lines 1164-1292 of build.log) the emacs executable is recompiled; src epaths.h gets recreated (line 1179). It looks like "make" is heavily confused.

You don't happen to have some remote-mounted partitions, e.g. /var mounted via NFS? From machines with a different system time?
Comment 20 Alex Deucher 2007-02-28 16:03:14 UTC
(In reply to comment #19)
> Hmm, at the beginning of the Install phase (lines 1164-1292 of build.log) the
> emacs executable is recompiled; src epaths.h gets recreated (line 1179). It
> looks like "make" is heavily confused.
> 
> You don't happen to have some remote-mounted partitions, e.g. /var mounted via
> NFS? From machines with a different system time?
> 

Nope. It's all local.
Comment 21 Ulrich Müller gentoo-dev 2007-02-28 16:54:27 UTC
Alex: Is the resulting epaths.h after "emerge install" (see comment #16) identical to the one that you have already posted in the attachment? If it differs, can you please post it here, too?
Comment 22 Alex Deucher 2007-02-28 18:13:29 UTC
Created attachment 111600 [details]
new epaths.h

It has changed a bit.
Comment 23 Ulrich Müller gentoo-dev 2007-02-28 20:48:37 UTC
(In reply to comment #22)
> Created an attachment (id=111600) [edit]
> new epaths.h
> It has changed a bit.

So this one contains the bad path constants. At this point (src_install) it should not be created at all (and Emacs should not be recompiled)!

I noticed also several warning messages in your build.log:
make[1]: warning: jobserver unavailable: using -j1.  Add `+' to parent make rule.

So somehow "make" gets confused, creating files in the wrong order or with wrong timestamps. But why does it happen? I must admit that I am at a loss here.

BTW, how to (artificially) reproduce the bug:
1. ebuild emacs-21.4-r7.ebuild compile
2. touch /var/tmp/portage/app-editors/emacs-21.4-r7/work/emacs-21.4/config.status
3. ebuild emacs-21.4-r7 merge
Comment 24 Alex Deucher 2007-02-28 21:29:44 UTC
(In reply to comment #23)
> (In reply to comment #22)
> > Created an attachment (id=111600) [edit]
> > new epaths.h
> > It has changed a bit.
> 
> So this one contains the bad path constants. At this point (src_install) it
> should not be created at all (and Emacs should not be recompiled)!
> 
> I noticed also several warning messages in your build.log:
> make[1]: warning: jobserver unavailable: using -j1.  Add `+' to parent make
> rule.
> 
> So somehow "make" gets confused, creating files in the wrong order or with
> wrong timestamps. But why does it happen? I must admit that I am at a loss
> here.
> 

Your guess is better than mine ;)  I'm glad it's finally working.  If you need me to try anything else let me know.
Comment 25 Ulrich Müller gentoo-dev 2007-02-28 23:03:19 UTC
(In reply to comment #24)
> I'm glad it's finally working.

(In reply to comment #17)
> > Could you run "ebuild /usr/portage/app-editors/emacs/emacs-21.4-r7.ebuild
> > install" again [...]
> 
> Very strange... doing that seems to have fixed emacs.  I no longer get the
> directory errors.

Caution. If you run "ebuild emacs-21.4-r7.ebuild clean" or cleanup /var/tmp, the errors will reappear...

Concerning the "make" warnings, you could try to do:
MAKEOPTS=-j1 emerge emacs
Comment 26 Christian Faulhammer (RETIRED) gentoo-dev 2007-03-01 06:55:22 UTC
(In reply to comment #25)
> Concerning the "make" warnings, you could try to do:
> MAKEOPTS=-j1 emerge emacs

 Will this also help to build Emacs correctly?  Maybe we can call sparc team, so they have a look, too.
Comment 27 Ulrich Müller gentoo-dev 2007-03-01 08:19:32 UTC
(In reply to comment #26)
> > MAKEOPTS=-j1 emerge emacs
> 
> Will this also help to build Emacs correctly?

No idea. I have never seen these "jobserver unavailable" warnings when compiling Emacs. Maybe it is a Sparc or SMP issue?

Furthermore, the first thing that "make" does (in src_compile and in src_install) is to execute ./config.status. Also this should not happen.

> Maybe we can call sparc team, so they have a look, too.

Good idea. Adding to CC.
Comment 28 Christian Faulhammer (RETIRED) gentoo-dev 2007-03-07 04:37:59 UTC
(In reply to comment #17)
> Very strange... doing that seems to have fixed emacs.  I no longer get the
> directory errors.

 Do you get those errors in emacs-cvs, by the way?  And Sparc, is it a sin on your platform to have MAKEOPTS=-j1?
Comment 29 Alex Deucher 2007-03-07 14:55:08 UTC
(In reply to comment #28)
> (In reply to comment #17)
> > Very strange... doing that seems to have fixed emacs.  I no longer get the
> > directory errors.
> 
>  Do you get those errors in emacs-cvs, by the way?  And Sparc, is it a sin on

which version is the cvs one?  pre22?

> your platform to have MAKEOPTS=-j1?
> 
No idea.  I don't see why it would be.
Comment 30 Christian Faulhammer (RETIRED) gentoo-dev 2007-03-07 15:25:54 UTC
(In reply to comment #29)
> (In reply to comment #28)
> > (In reply to comment #17)
> > > Very strange... doing that seems to have fixed emacs.  I no longer get the
> > > directory errors.
> > 
> >  Do you get those errors in emacs-cvs, by the way?  And Sparc, is it a sin > > on
> which version is the cvs one?  pre22?

 Yep.  Choose .95 or .9999

> > your platform to have MAKEOPTS=-j1?
> No idea.  I don't see why it would be.

 Maybe compilation gets sloooooow.  Depends on the number of CPUs/kernels, I suppose.  MAKEOPTS=-j1 does help in your case?
Comment 31 Christian Faulhammer (RETIRED) gentoo-dev 2007-04-19 07:23:24 UTC
(In reply to comment #29)
> (In reply to comment #28)
> > (In reply to comment #17)
> > > Very strange... doing that seems to have fixed emacs.  I no longer get the
> > > directory errors.
> >  Do you get those errors in emacs-cvs, by the way?  And Sparc, is it a sin on
> which version is the cvs one?  pre22?

 Alex, did you check with the CVS versions?
Comment 32 Ulrich Müller gentoo-dev 2007-04-22 19:43:09 UTC
It seems that we cannot do anything here without further input, so resolving as NEEDINFO. Please reopen if this is still an issue, and if you can provide us with further information.
Comment 33 Alex Deucher 2007-04-22 22:30:30 UTC
(In reply to comment #32)
> It seems that we cannot do anything here without further input, so resolving as
> NEEDINFO. Please reopen if this is still an issue, and if you can provide us
> with further information.
> 

Sorry, I've been swamped this week and haven't had a spare moment.  I'll update as soon as I get a chance to test cvs emacs.