Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

"emerge nmh" fails with the following message:

--------------------------- ACCESS VIOLATION SUMMARY---------------------------
LOG FILE = "/tmp/sandbox-nmh-1.0.4-7475.log"

open_wr:   /.nonexist-file.swp
open_wr:   /.nonexist-file.swp
open_wr:   /root/tmp/nonexist-file.swp
open_wr:   /root/tmp/nonexist-file.swp
--------------------------------------------------------------------------------

The machine details are:
Linux ivpcl04 2.4.19-r1 #2 Thu May 2 10:05:56 BST 2002 i686 GenuineIntel

from /etc/make.conf:

CHOST="i686-pc-linux-gnu"
CFLAGS="-march=i686 -O3 -pipe"
CXXFLAGS="-march=i686 -O3 -pipe"

I can't replicate this.  What portage version are you using?

I used portage-1.9.5. 
When 1.9.6 becomes available from http://www.ibiblio.org/gentoo/snapshots/
I'll try that too. I can't use "emerge rsync" at present:
>>> starting rsync with rsync://cvs.gentoo.org/gentoo-x86-portage...
rsync: failed to connect to cvs.gentoo.org: Connection refused
rsync error: error in socket IO (code 10) at clientserver.c(89)

Portage 1.9.6 gives the same result.

I can't reproduce this either with 1.9.6-r1. The depends for this ebuild are
slightly wrong though and i'll correct that.

In the meantime, please post your USE flags.

cleaned up ebuild for recent portages in -r1

I used the default USE flags for 1.1a.
I succeeded in getting nmh to work by downloading the source from
http://www.mhost.com/nmh/ and compiling it.

I still can't reproduce this even by matching your USE set. I'll reopen this
bug
and assign it to seeman@gentoo.org so that he can delegate it to other
developers who may be able to reproduce it.

seemant, i can't reproduce this one to fix it.

I've now tried this on an Athlon in addition to the P4 on which I first
reported
the problem, with exactly the same results.
Both machines were built with the stage 3 tar file (rsync is blocked).

Az, help!

Dont know .. tried it in a xterm .. console ... "su" to root and not "su -",
but it works every time.

Do understand, Im not saying that you do not have this problem .. its rather
some ENV variable set, or not set, or some or other package that is installed,
or not, or not a certain version ...

Maybe do:

# cd /var/db/pkg
# find . > /tmp/foo

and mail foo

also attatch the output of "set" (all the env variables).

What might be interesting, is if you could try to use the 16mb image and
do a build from there and then try merging nmh, rather than stage 3.

I also have exactly the same problem...

What I do is cross-compile in a chrooted environment, from stage 1 only. All other packages I've emerged up to now worked.

I also use 1.1.a; USE="-mmx -3dnow -sse", CFLAGS="-mcpu=i486 -march=i486 -fomit-frame-pointer -O3 -fno-exceptions -funroll-loops" (That's why I cross-compile :-). Apart from that, nothing special at all.

Hope this helps...

Just a "Me Too".  nmh-1.0.4-r1 with portage version 1.9.13.  With the
following:

USE="-kde -gnome alsa -arts tcltk ncurses readline gif png tiff jpeg -esd imap
spell tetex gpm -3dnow qt python perl oogvorbis opengl sdl -postgres truetype
empeg encode mmx xml -cups"

CHOST="i686-pc-linux-gnu"
CFLAGS="-march=i686 -O3 -pipe"
CXXFLAGS="-march=i686 -O3 -pipe"

I've tried it from the console and from a rxvt term in WindowMaker.  Here's the
result of set on my machine.  This is a pretty new install from earlier in the
week.

BASH=/bin/bash
BASH_VERSINFO=([0]="2" [1]="05a" [2]="0" [3]="1" [4]="release"
[5]="i686-pc-linux-gnu")
BASH_VERSION='2.05a.0(1)-release'
CLASSPATH=/opt/blackdown-jdk-1.3.1/jre/lib/rt.jar
COLORFGBG='default;default;0'
COLORTERM=rxvt-xpm
COLUMNS=80
CVS_RSH=ssh
DIRSTACK=()
DISPLAY=:0.0
EDITOR=/usr/bin/nano
EUID=1000
GNUSTEP_LOCAL_ROOT=/usr/lib/GNUstep
GROUPS=()
HISTFILE=/home/destefan/.bash_history
HISTFILESIZE=500
HISTSIZE=500
HOME=/home/destefan
HOSTNAME=adx.destefan.homeip.net
HOSTTYPE=i686
IFS=$' \t\n'
INFODIR=/usr/share/info:/usr/X11R6/info
INPUTRC=/etc/inputrc
JAVAC=/opt/blackdown-jdk-1.3.1/bin/javac
JAVA_HOME=/opt/blackdown-jdk-1.3.1
JDK_HOME=/opt/blackdown-jdk-1.3.1
LESSOPEN='|lesspipe.sh %s'
LINES=24
LOGNAME=destefan
LS_COLORS='no=00:fi=00:di=01;34:ln=01;36:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.gz=01;31:*.bz2=01;31:*.deb=01;31:*.rpm=01;31:*.jpg=01;35:*.gif=01;35:*.bmp=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.png=01;35:*.mpg=01;35:*.avi=01;35:*.fli=01;35:*.gl=01;35:*.dl=01;35:'
MACHTYPE=i686-pc-linux-gnu
MAILCHECK=60
MANPATH=/usr/share/man:/usr/X11R6/man
MOZILLA_FIVE_HOME=/usr/lib/mozilla
OLDPWD=/home/destefan
OPTERR=1
OPTIND=1
OSTYPE=linux-gnu
PAGER=/usr/bin/less
PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin:/opt/blackdown-jdk-1.3.1/bin:/o
pt/blackdown-jdk-1.3.1/jre/bin:/usr/qt/3/bin
PIPESTATUS=([0]="0")
PPID=5359
PS1='\[\033[01;32m\]\u@\h \[\033[01;34m\]\W \$ \[\033[00m\]'
PS2='> '
PS4='+ '
PWD=/tmp
QMAKESPEC=linux-g++
QTDIR=/usr/qt/3
SHELL=/bin/bash
SHELLOPTS=braceexpand:hashall:histexpand:monitor:history:interactive-comments:emacs
SHLVL=1
TERM=xterm
UID=1000
USER=destefan
VIMRUNTIME=/usr/share/vim/vim61
WINDOWID=8388610
WMAKER_BIN_NAME=wmaker
WRASTER_COLOR_RESOLUTION0=4
XINITRC=/etc/X11/xinit/xinitrc
_=/etc/make.conf

Finally got it to work by re-installing the machine from stage 1.

This occurs when there is no valid /usr/bin/vi.  Even just a symlink to
/usr/bin/vim fixes this problem (I had this).  So for now added 
app-editors/vi as DEPEND until somebody with more time can resolve this
in a more fasionable way.

Sorry but I do have a link from vim to /usr/bin/vi, and I'm
still unable to emerge, with the same error...

OK, scrap the symlink from /usr/bin/vim to /usr/bin/vi as a fix then. You need
vi installed, AFAIK.

Ok, for some weird reason I cannot reproduce it anymore.  Can somebody
with this problem try the following:

Edit /usr/lib/portage/bin/ebuild.sh and search for the line:

    export S D

then add just below it:

   export TMPDIR="${T}"

Giving you:

------------------------snip------------------------------------
    #our custom version of libtool uses $S and $D to fix
    #invalid paths in .la files
    export S D
    export TMPDIR="${T}"
    src_compile
    cd ${BUILDDIR}
    touch .compiled
    if [ ! -e "build-info" ]
    then
        mkdir build-info
    fi
    cd build-info
------------------------snip------------------------------------

And try to remerge nmh.

No luck with the fix, but emerging vi did solve the problem.
Seems like there's some weird kind of dependency with vi indeed...

Ok, so stock should work now.

The solution in comment #18 did not fix the problem. Using
/home/cvsroot/gentoo-src/portage/bin/ebuild.sh,v 1.125 2003/05/12 09:
10:27, which has the changes mentioned:

        #some users have $TMP/$TMPDIR to a custom dir in their home ...
        #this will cause sandbox errors with some ./configure
        #scripts, so set it to $T.
        export TMP="${T}"
        export TMPDIR="${T}"

I still get the access violation.

For nmh-1.0.4-r2.ebuild, app-editors/vi is still listed as a dependency. The
above problem occurs only when that dependency is removed.

However, who wants to merge app-editors/vi? It sucks (IMHO). I think a better
solution may be to make all the VIs provide virtual/vi and make nmh depend on
virtual/vi.

Since nmh seems to be used by myself and a few other people, a sufficient hack
may be to simply change nmh-1.0.4-r2.ebuild to have

[ -f /usr/bin/vi ] || die

in src_compile().