Bugzilla Bug 91571

# emerge gnome-base/eel
...
>>> Test phase [check]: gnome-base/eel-2.10.0
Making check in eel
make[1]: Entering directory `/var/tmp/portage/eel-2.10.0/work/eel-2.10.0/eel'
make  check-TESTS
make[2]: Entering directory `/var/tmp/portage/eel-2.10.0/work/eel-2.10.0/eel'
Could not set mode 0700 on private per-user gnome configuration directory `/root/.gnome2_private/': Permission denied
FAIL: check-eel
===================
1 of 1 tests failed
===================
make[2]: *** [check-TESTS] Error 1
make[2]: Leaving directory `/var/tmp/portage/eel-2.10.0/work/eel-2.10.0/eel'
make[1]: *** [check-am] Error 2
make[1]: Leaving directory `/var/tmp/portage/eel-2.10.0/work/eel-2.10.0/eel'
make: *** [check-recursive] Error 1

!!! ERROR: gnome-base/eel-2.10.0 failed.
!!! Function src_test, Line 566, Exitcode 0
!!! Make check failed. See above for details.
!!! If you need support, post the topmost build error, NOT this status message.


# emerge info
Portage 2.0.51.21-r1 (default-linux/x86/2005.0, gcc-3.4.3-20050110, glibc-2.3.4.20050125-r1, 2.6.11-gentoo-r7 i686)
=================================================================
System uname: 2.6.11-gentoo-r7 i686 Intel(R) Pentium(R) M processor 1.70GHz
Gentoo Base System version 1.6.11
ccache version 2.4 [enabled]
dev-lang/python:     2.3.5
sys-apps/sandbox:    1.2.5
sys-devel/autoconf:  2.13, 2.59-r6
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.5
sys-devel/binutils:  2.15.92.0.2-r8
sys-devel/libtool:   1.5.16
virtual/os-headers:  2.6.11
ACCEPT_KEYWORDS="x86 ~x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2 -pipe -march=pentium3 -ffast-math -fomit-frame-pointer"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /var/bind /var/qmail/alias /var/qmail/control /var/vpopmail/domains /var/vpopmail/etc"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O2 -pipe -march=pentium3 -ffast-math -fomit-frame-pointer"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs autoconfig ccache collision-protect distlocks maketest sandbox sfperms strict test"
GENTOO_MIRRORS="ftp://ftp.linux.kiev.ua/pub/Linux/Gentoo"
LANG="ru_RU.UTF-8"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.gentoo.org.ua/gentoo-portage"
USE="x86 X acpi alsa apache2 apm avi berkdb bitmap-fonts cairo cdr crypt curl divx4linux dvd emboss encode fam ffmpeg flac fluidsynth foomaticdb freetype gd gdbm gif glitz glut gnome gtk gtk2 hal imagemagick imlib ithreads jpeg libg++ libwww lzo mmap mmx mozdevelop mozilla mp3 mysql ncurses network nls nowin nptl nptlonly ogg oggvorbis opengl pam pdflib perl pic png pnp postgres pthreads qmail readline samba sdl slang sounds sse sse2 ssl stream symlink tcpd threads truetype truetype-fonts type1-fonts unicode userlocales utf8 v4l v4l2 vim-with-x vlm vorbis wxwindows xml2 xmms xv xvid zlib zvbi userland_GNU kernel_linux elibc_glibc"
Unset:  ASFLAGS, CTARGET, LC_ALL, LDFLAGS, LINGUAS

I can reproduce this on amd64 too using usersandbox...  I added RESTRICT=test
so
I can get it marked on amd64... 

and the nautilus tests also fail because they try to write to /root/... I guess
that's another case of RESTRICT=test

I added RESTRICT=test .. I guessed you dont plan on fixing the tests..

no we don't restrict because it pointless to even have tests then.

*** This bug has been marked as a duplicate of 71061 ***

Are you planning to fix the tests? I read your answer to bug #69343 .. and the
problem here isnt that the test it broken, but that it requires the whole gnome
env running. That's why RESTRICT=test is there... 

That said, they are you packages, and I'm sorry if I did something wrong. I can
revert the changes if its what you want.

The fail here for one doesn't need X or gnome and probably could be dealt with
in a suitable manner now I think of it.

I consider it bad behaviour to disable tests because they fail (for whatever
reason), the point of the maketest is to make sure that all tests succeed, but
all that is covered in the duplicate bug. On the other hand we don't have the
time to go around fixing trivial tests in packages that work mostly fine, so we
leave it up to our users to suggest fixes if they encounter these failing tests.
Reality is, so far noone has come up with anything, evidently it's not so
important after all.

I'd think it's better to have tests fail and let users who use maketest
themselves decide what is the right course of action, silently disabling the
tests is really kicking all ground away underneath the whole feature.