On 04/06/10 02:43, Paul Hartman wrote: > On Mon, Apr 5, 2010 at 10:53 AM, Paul Hartman > <paul.hartman+gen...@gmail.com> wrote: >> On Mon, Apr 5, 2010 at 9:15 AM, Paul Hartman >> <paul.hartman+gen...@gmail.com> wrote: >>> On Sun, Apr 4, 2010 at 5:00 PM, Lie Ryan <lie.1...@gmail.com> wrote: >>>> I'm running with full system FEATURES="test" on, and I have a couple of >>>> programs that depended on dev-libs/boost. The boost testsuite always >>>> fails in my computer due to insufficient disk space, I usually simply >>>> skip the test for boost and just go on with the merge. But today, I >>>> decided to let the testsuite run to completion; so in preparation for >>>> that, I plugged in an external harddisk and made it so that >>>> /var/tmp/portage points to an empty disk image in the external harddrive. >>>> >>>> This setup works ok, and the testsuite is still running, however I saw >>>> now that the disk image's is now taking ~18 GB (and counting) while "du >>>> -sh" on /var/tmp/portage counted ~13GB. >>>> >>>> So, the question is, has anyone successfully compiled and run >>>> FEATURES="test" on boost and knows how much space the tests eat up in >>>> the end? >>>> >>>> I am suspecting of the possibility that maybe a testsuite gets into an >>>> infinite loop while writing a file or something constantly eats up >>>> diskspace. Or is it just that boost has an outrageously too extensive >>>> testsuite and it will turn out ok if I just left it to run. >>> >>> I'm trying it now, I have 64gb free in /var/tmp so I hope that's enough... >>> :) >>> >> >> After almost 1.5 hours it is at its 22000th target and using 14G of >> /var/tmp so far... I'll keep waiting. >> > > It finished, successfully. 1 hour 52 minutes (normal compile of boost > without testing takes about 3 minutes). Peak disk usage was about 20G > when i spot-checked...
Finished too (sorry didn't post the update earlier). And passed the test too, great. Thank you for trying it as well! Final count: the disk image's size is now ~22G but I don't know how large the real disk usage in the end is since portage cleaned the /var/tmp/portage. That's one hell of a test! > The ebuild checks for 1024M free, maybe they need to change that to > check for 20G if testing? I think so too. Let's see if I can file a bug on that. Done: http://bugs.gentoo.org/show_bug.cgi?id=313315 --- Anyway, I've been thinking about this for some time that turning on FEATURES="test" globally seems quite impractical for many users due to some test suites that: - takes a disproportionally huge amount of time to finish - takes a huge amount of harddisk - takes a huge amount of memory - pulled out optional dependencies used only for testing - ships with a test that unconditionally fails (e.g. unimplemented feature) but not marking it "expected failure" - other behavioral problems (using network, restarting, etc though I've never seen these sort of crime yet as of now, probably they're already filtered before it reaches me) Due to this problem, I think portage could have a test policy feature so people can have finer control to filter out test suites that they don't want to run. This way globally FEATURES="test" can be more feasible for most users (and probably can sometime be turned on by default). So is there anyone here that actually wanted to run FEATURES="test" globally, but are turned off when experiencing the problems it brings? Do you think if we want to hack this policy feature into portage or emerge, what's the best option? Using USE-flags won't require much change to emerge and portage but is quite inflexible; or new variables in ebuild file; or a separate (optional) test description file that portage will read and compare with the system's policy. Have better alternative?
