Bugzilla Bug 43134

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 an attachment (id=27278) [edit]
The compile process output

The compiling seems to work, but it stuff borks up my DRI.

Created an attachment (id=27280) [edit]
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...