When I tried to emerge museseq-0.6.2 I got an access violation, it seems to happen and the end of the compile when the permissions of some files are changed. Reproducible: Always Steps to Reproduce: 1. emerge museseq 2. 3. Actual Results: if test "no" = "yes"; then \ su -c "chown root muse; chmod +s muse"; \ fi touch stamp-chown make[2]: Leaving directory `/var/tmp/portage/museseq-0.6.2/work/muse-0.6.2' make[1]: Leaving directory `/var/tmp/portage/museseq-0.6.2/work/muse-0.6.2' --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE = "/tmp/sandbox-media-sound_-_museseq-0.6.2-22769.log" open_wr: /dev/dri/card0 open_wr: /dev/dri/card0 open_wr: /dev/dri/card1 open_wr: /dev/dri/card1 open_wr: /dev/dri/card2 open_wr: /dev/dri/card2 open_wr: /dev/dri/card3 open_wr: /dev/dri/card3 open_wr: /dev/dri/card4 open_wr: /dev/dri/card4 open_wr: /dev/dri/card5 open_wr: /dev/dri/card5 open_wr: /dev/dri/card6 open_wr: /dev/dri/card6 open_wr: /dev/dri/card7 open_wr: /dev/dri/card7 open_wr: /dev/dri/card8 open_wr: /dev/dri/card8 open_wr: /dev/dri/card9 open_wr: /dev/dri/card9 open_wr: /dev/dri/card10 open_wr: /dev/dri/card10 open_wr: /dev/dri/card11 open_wr: /dev/dri/card11 open_wr: /dev/dri/card12 open_wr: /dev/dri/card12 open_wr: /dev/dri/card13 open_wr: /dev/dri/card13 open_wr: /dev/dri/card14 open_wr: /dev/dri/card14 -------------------------------------------------------------------------------- Portage 2.0.50-r1 (default-x86-1.4, gcc-3.3.2, glibc-2.3.3_pre20040117-r0, 2.4.23) ================================================================= System uname: 2.4.23 i686 AMD Athlon(tm) XP 3200+ Gentoo Base System version 1.4.3.12 distcc 2.12.1 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] Autoconf: sys-devel/autoconf-2.59-r3 Automake: sys-devel/automake-1.8.2 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-O3 -march=athlon-xp -pipe" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-O3 -march=athlon-xp -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs buildpkg ccache sandbox" GENTOO_MIRRORS="ftp://ftp.snt.utwente.nl/pub/os/linux/gentoo rsync://ftp.snt.utwente.nl/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnow X aalib alsa apache2 apm avi berkdb cdr crypt cups encode foomaticdb gatos gdbm gif gnome gpm gtk gtk2 imlib joystick jpeg libg++ libwww mad matroska mikmod mmx mozilla mpeg mysql ncurses oggvorbis opengl oss pam pdflib png python quicktime radeon readline samba sdl slang sse ssl svga tcpd tetex truetype unicode vhost video_cards_radeon x86 xml xml2 xmms xv zlib"
hmm... works fine for me... It shouldn't be doing anything with DRI... Is the 0.6.0 ebuild working fine?
museseq-0.6.0 gives the same access violation but just after the configure stage. This is what I find in my logs: Feb 29 12:57:57 [devfsd] error calling: "unlink" in "GLOBAL"_ It doesn't only give an access violation, but it screws up my whole DRI. This might be a sandbox problem and not a museseq problem.
Can someone familiar with sandbox comment on this... I don't see where the dri access is coming from...
chances are the program is trying to run an X related app and as such, wrongly tries to open the display
Can you attatch the output of: 'ebuild --verbose --debug museseq-0.6.2 install' after doing the 'ebuild --verbose --debug museseq-0.6.2 compile'
Created attachment 27278 [details] The compile process output The compiling seems to work, but it stuff borks up my DRI.
Created attachment 27280 [details] Ouput of the installation process The installation also works when done with ebuild.
what? That's weird... try emerging it again...
I've tried it a few times. A normal emerge doesn't work because of the dri error. The ebuild compile, ebuild install routine works. Ebuild compile does break my dri, but ebuild install installs like it's suppost to.
so if you do 'ebuild <ebuild> compile install qmerge' it works, but if you do 'emerge <ebuild>' it fails? That doesn't seem right to me, as it was my understanding that emerge did just that...
The dri errors happen at the end of the compile process, and emerge fails on the errors, but when I do a ebuild install after it, it does install.
ok... this is a big 'wtf' for me... portage guys: is there any reason why 'ebuild <blah> qmerge' would succeed but 'emerge <blah>' would have sandbox violations?
I think I'm rambling too much, but let me explain it again. 1) emerge museseq: fails at the end of the compile process because of the above mentioned dri errors 2) ebuild compile: gives the same errors at the end of the compile When I do either of the two, I can do an ebuild install and that works. Ebuild notices that the program has already been compiled and just installs it. At the end om the compile process attachment you can see the dri errors. http://bugs.gentoo.org/attachment.cgi?id=27278&action=view
oh ok, so you ARE still getting the sandbox violations at the end of compile... ok... I'll see what I can gather from that log...
ok, this should be fixed now in portage...
