gnome-base/nautilus-2.14.1 fails with FEATURES="test". make[3]: Entering directory `/var/tmp/portage/nautilus-2.14.1/work/nautilus-2.14.1/src' make check-TESTS make[4]: Entering directory `/var/tmp/portage/nautilus-2.14.1/work/nautilus-2.14.1/src' GnomeUI-WARNING **: While connecting to session manager: Authentication Rejected, reason : None of the authentication protocols specified are supported and host-based authentication failed. aborting... ./check-nautilus: line 2: 17848 Aborted ./nautilus --check --g-fatal-warnings FAIL: check-nautilus ========================================================================= 1 of 1 tests failed Please report to http://bugzilla.gnome.org/enter_bug.cgi?product=nautilus ========================================================================= make[4]: *** [check-TESTS] Error 1 make[4]: Leaving directory `/var/tmp/portage/nautilus-2.14.1/work/nautilus-2.14.1/src' make[3]: *** [check-am] Error 2 make[3]: Leaving directory `/var/tmp/portage/nautilus-2.14.1/work/nautilus-2.14.1/src' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/var/tmp/portage/nautilus-2.14.1/work/nautilus-2.14.1/src' make[1]: *** [check] Error 2 make[1]: Leaving directory `/var/tmp/portage/nautilus-2.14.1/work/nautilus-2.14.1/src' make: *** [check-recursive] Error 1 !!! ERROR: gnome-base/nautilus-2.14.1 failed. Call stack: ebuild.sh, line 1546: Called dyn_test ebuild.sh, line 986: Called src_test nautilus-2.14.1.ebuild, line 73: Called die !!! Test phase failed !!! If you need support, post the topmost build error, and the call stack if relevant.
This also happens with nautilus-2.16.3. It looks like the test want to connect to the current gnome session, but with the session running as a user and the emerge running as root this causes a mismatch.
I tried on a 2.16 box over ssh and it passes tests. Maybe try to unset DISPLAY or X* env vars if you are compiling from a terminal in X.
I am compiling from a terminal in an X session. If I shell into my own box and compile, then the tests pass for me as well. Unsetting DISPLAY in my normal environment does have the right effect, but unfortunately does not solve the problem. When DISPLAY is unset, the ebuild (using the virtualx class) correctly starts Xvfb to do its thing: >>> Source compiled. * Scanning for an open DISPLAY to start Xvfb ... * Starting Xvfb on $DISPLAY=1 ... Making check in libnautilus-extension However, it still fails: make[4]: Entering directory `/var/tmp/portage/gnome-base/nautilus-2.18.1/work/nautilus-2.18.1/src' GnomeUI-WARNING **: While connecting to session manager: Authentication Rejected, reason : None of the authentication protocols specified are supported and host-based authentication failed. aborting... ./check-nautilus: line 2: 11413 Aborted ./nautilus --check --g-fatal-warnings FAIL: check-nautilus ========================================================================= 1 of 1 tests failed Please report to http://bugzilla.gnome.org/enter_bug.cgi?product=nautilus ========================================================================= The additional culprit is the SESSIONMANAGER variable. After unsetting this as well the tests run without issue. So it seems there are two issues here: 1. virtualx.eclass should probably also unset SESSIONMANAGER (in addition XAUTHORITY) to be on the safe side) 2. should the nautilus ebuild unset DISPLAY? It seems unlikely that this will ever work in the current setup for any user compiling stuff in an X terminal.
Hans, do you still get that bug with nautilus 2.18 ? If so, please update the bug summary so that it doesn't get lost :) Thanks
Yes, still same problem with 2.18.3: make check-TESTS make[4]: Entering directory `/var/tmp/portage/gnome-base/nautilus-2.18.3/work/nautilus-2.18.3/src' GnomeUI-WARNING **: While connecting to session manager: Authentication Rejected, reason : None of the authentication protocols specified are supported and host-based authentication failed. aborting... ./check-nautilus: line 2: 7132 Aborted ./nautilus --check --g-fatal-warnings FAIL: check-nautilus ========================================================================= 1 of 1 tests failed Please report to http://bugzilla.gnome.org/enter_bug.cgi?product=nautilus ========================================================================= make[4]: *** [check-TESTS] Error 1 make[4]: Leaving directory `/var/tmp/portage/gnome-base/nautilus-2.18.3/work/nautilus-2.18.3/src' make[3]: *** [check-am] Error 2 make[3]: Leaving directory `/var/tmp/portage/gnome-base/nautilus-2.18.3/work/nautilus-2.18.3/src' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/var/tmp/portage/gnome-base/nautilus-2.18.3/work/nautilus-2.18.3/src' make[1]: *** [check] Error 2 make[1]: Leaving directory `/var/tmp/portage/gnome-base/nautilus-2.18.3/work/nautilus-2.18.3/src' make: *** [check-recursive] Error 1
Confirmed that this still happens with nautilus-2.20.0
ok, so there is something wrong here. I'm pretty sure you are using su to get root and install stuff. Please do the following test : Get root with : sudo -s (provided you have it installed) su su - and look at your env. Only when using su alone you'll get SESSION_MANAGER still set, hence the breakage. Afaik the ebuild should still compile so I think fixing the ebuild in src_test is the right thing to do. Is there any other ebuild failing in a similar way for you ?
(In reply to comment #7) > sudo -s (provided you have it installed) > su > su - > > and look at your env. Only when using su alone you'll get SESSION_MANAGER still > set, hence the breakage. Confirmed. I am using 'su', and both 'sudo -s' and 'su -' wipe out the SESSION_MANAGER environment variable. I can't recall other ebuilds failing in the same way, but I'm not sure I'm using any other ebuilds that test with the virtual X stuff. Afaik the ebuild should still compile so I think > fixing the ebuild in src_test is the right thing to do. Is there any other > ebuild failing in a similar way for you ? >
I commited a change to unset the SESSION_MANAGER in src_test, not sure this is the best solution but somebody will cry if it's not anyway. If it doesn't fix your bug, please reopen.
Works fine for me with nautilus-2.20.0-r1. Thanks!
