Re: [gentoo-dev] controlling src_test
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 test is in FEATURES. Therefore the FEATURES check in the default src_test() is redundant. -- Bo Andresen signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] controlling src_test
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 like a simple consistent way to mark or handle these packages
> without disabling tests altogether (RESTRICT=test). As mentioned
> recently, checking ${FEATURES} in an ebuild is frowned upon, and it
> doesn't seem right to handle this on a per-ebuild basis. How would
> something like this best be implemented? A split up RESTRICT
> (test_userpriv/test_nouserpriv)? test.eclass? Something else?
> Looking at the bigger picture, are there any other situations where
> finer-grained control over the test system would be helpful?
See http://bugs.gentoo.org/show_bug.cgi?id=159876 for some suggestions
for the "test-only-as-root" case. IMO ebuilds should simply test for
the actual capabilities they need in src_test (like uid) instead of
more abstract things like userpriv. If such tests can be used in
several ebuilds an eclass can help to standardize them, but I don't see
a reason to move that logic into the package manager unless those cases
are extremely common.
As for fine-grained user-control, it's a question of quantification as
discussed previously, which isn't easy to solve, or you have to
en-/disable things manually and the issue is part tf the
per-package-env-variables problem (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)
Marius
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] controlling src_test
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. We've already had this discussion before [1] and there is no one-size-fits-all solution for tagging tests. Ryan's plan only proposes to enable/disable tests based on whether they can run inside a sandbox. That much is doable. Trying to quantify the time a test suite will take to complete is impossible : different arches, vastly different CPU clock speeds, same for HDDs sizes and speeds, ... is impossible. Basically, it boils down to "if you're running FEATURES=test, you should know what you're doing". +1 on Ryan's idea Rémi [1] http://archives.gentoo.org/gentoo-dev/msg_145157.xml -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] controlling src_test
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 root and some fail if not run as root.
> > >
> > > I'd like a simple consistent way to mark or handle these packages
> >
> > without
> >
> > > disabling tests altogether (RESTRICT=test). As mentioned recently,
> >
> > checking
> >
> > > ${FEATURES} in an ebuild is frowned upon, and it doesn't seem right
> >
> > to handle
> >
> > > this on a per-ebuild basis. How would something like this best be
> >
> > implemented?
> >
> > > A split up RESTRICT (test_userpriv/test_nouserpriv)? test.eclass?
> >
> > Something
> >
> > > else? Looking at the bigger picture, are there any other situations
> >
> > where
> >
> > > finer-grained control over the test system would be helpful?
> > >
> > > While I'm on the subject, I also thought it would be cool to have
> >
> > the option to
> >
> > > not die on a src_test failure, but instead to dump the log file and
> >
> > continue
> >
> > > on to the install phase. I know this can be done per-ebuild, but
> >
> > it'd be
> >
> > > a useful global option.
> >
> > 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.
> >
> > --Ravi
>
> Who and what determines if a test is overly comprehensive and takes too
> long to run?
I think most everybody agrees that boost's tests are overly comprehensive. As
for others like mysql, a long test may be necessary to ensure everything is
working properly.
--
2.6.22-gentoo-r8
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] controlling src_test
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 way to mark or handle these packages
> without
> > disabling tests altogether (RESTRICT=test). As mentioned recently,
> checking
> > ${FEATURES} in an ebuild is frowned upon, and it doesn't seem right
> to handle
> > this on a per-ebuild basis. How would something like this best be
> implemented?
> > A split up RESTRICT (test_userpriv/test_nouserpriv)? test.eclass?
> Something
> > else? Looking at the bigger picture, are there any other situations
> where
> > finer-grained control over the test system would be helpful?
>
> > While I'm on the subject, I also thought it would be cool to have
> the option to
> > not die on a src_test failure, but instead to dump the log file and
> continue
> > on to the install phase. I know this can be done per-ebuild, but
> it'd be
> > a useful global option.
>
>
> 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.
>
> --Ravi
>
Who and what determines if a test is overly comprehensive and takes too
long to run?
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] controlling src_test
-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 simple consistent way to mark or handle these packages without
> disabling tests altogether (RESTRICT=test). As mentioned recently, checking
> ${FEATURES} in an ebuild is frowned upon, and it doesn't seem right to handle
> this on a per-ebuild basis. How would something like this best be
> implemented?
> A split up RESTRICT (test_userpriv/test_nouserpriv)? test.eclass? Something
> else? Looking at the bigger picture, are there any other situations where
> finer-grained control over the test system would be helpful?
>
> While I'm on the subject, I also thought it would be cool to have the option
> to
> not die on a src_test failure, but instead to dump the log file and continue
> on to the install phase. I know this can be done per-ebuild, but it'd be
> a useful global option.
>
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.
- --Ravi
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHBI2JsDgfoknqAqMRAj7+AKDY1wJYClm13wmxMWxgGxCfqzlfOwCgl2tT
qXwJ8Cz5HL+W1ois4IRzvOw=
=CjAo
-END PGP SIGNATURE-
--
[EMAIL PROTECTED] mailing list
[gentoo-dev] controlling src_test
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
disabling tests altogether (RESTRICT=test). As mentioned recently, checking
${FEATURES} in an ebuild is frowned upon, and it doesn't seem right to handle
this on a per-ebuild basis. How would something like this best be implemented?
A split up RESTRICT (test_userpriv/test_nouserpriv)? test.eclass? Something
else? Looking at the bigger picture, are there any other situations where
finer-grained control over the test system would be helpful?
While I'm on the subject, I also thought it would be cool to have the option to
not die on a src_test failure, but instead to dump the log file and continue
on to the install phase. I know this can be done per-ebuild, but it'd be
a useful global option.
--
fonts / wxWindows / gcc-porting / treecleaners
9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8)
--
[EMAIL PROTECTED] mailing list
