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