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
Is it possible your bug is also Bug #22563?
(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.
Alex, does the problem persist with the latest version of 21.4-r7 and/or emacs-cvs?
(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?
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?
(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'
(In reply to comment #6) > # ebuild emacs-21.4-r7.ebuild compile You did that in the ebuild's directory?
(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.
(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/.
Created attachment 111315 [details] config.status
Created attachment 111316 [details] epaths.h
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"?
(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.
(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. :-/
(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/"
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?
(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.
Created attachment 111565 [details] build.log
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?
(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.
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?
Created attachment 111600 [details] new epaths.h It has changed a bit.
(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
(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.
(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
(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.
(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.
(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?
(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.
(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?
(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?
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.
(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.
