-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ryan Hill wrote:
There are several packages in portage (and even in base-system) that fail
in src_test when userpriv/usersandbox is enabled or disabled. That is, some
testsuites fail when run as root and some fail if not run as root.
I'd like a
Ravi Pinjala wrote:
Ryan Hill wrote:
There are several packages in portage (and even in base-system) that
fail
in src_test when userpriv/usersandbox is enabled or disabled. That
is, some
testsuites fail when run as root and some fail if not run as root.
I'd like a simple consistent
Ravi Pinjala a écrit :
I, for one, would like to be able to control whether or not to run tests
that take a huge amount of time to run. Some test suites are
ridiculously comprehensive, and if we could have an option to disable
only those, or even run a reduced test suite, that'd be pretty neat.
On Thursday 04 October 2007 09:36:29 Doug Goldstein wrote:
Ravi Pinjala wrote:
Ryan Hill wrote:
There are several packages in portage (and even in base-system) that
fail
in src_test when userpriv/usersandbox is enabled or disabled. That
is, some
testsuites fail when run as
On Wed, 03 Oct 2007 19:50:01 -0600
Ryan Hill [EMAIL PROTECTED] wrote:
There are several packages in portage (and even in base-system) that
fail in src_test when userpriv/usersandbox is enabled or disabled.
That is, some testsuites fail when run as root and some fail if not
run as root.
I'd
On Friday 05 October 2007 01:14:32 Marius Mauch wrote:
(btw, the /etc/portage/env trick only works because the default src_test in
ebuild.sh has the otherwise redundant FEATURES check which was discussed a
few days ago in one of the commit reviews)
src_test() is not called in dyn_test() unless
There are several packages in portage (and even in base-system) that fail
in src_test when userpriv/usersandbox is enabled or disabled. That is, some
testsuites fail when run as root and some fail if not run as root.
I'd like a simple consistent way to mark or handle these packages without