1 |
On Tue, 22 Mar 2011 13:09:46 +0100 |
2 |
"Paweł Hajdan, Jr." <phajdan.jr@g.o> wrote: |
3 |
|
4 |
> On 3/21/11 11:02 PM, Ryan Hill wrote: |
5 |
> > It does to me, I use them all the time. ;) The important part is that we |
6 |
> > install the test results, which can then be used for regression testing when |
7 |
> > rolling patchsets. |
8 |
> |
9 |
> I see, it makes sense. I guess you're comparing the test results before |
10 |
> and after rolling patchsets and look for regressions. |
11 |
> |
12 |
> > I think that glibc and gcc tests and other testsuites that nearly always |
13 |
> > fail shouldn't be run for the average user but should still be easily |
14 |
> > accessible in a standard way. I think we need a more finely grained test |
15 |
> > setup, where we can say tests are "expensive" or "interesting only to |
16 |
> > developers" or "known to fail", and let people opt-in to these on a |
17 |
> > per-package basis. Right now you always have to opt-out using |
18 |
> > package.use.mask which "works" but is unintuitive. |
19 |
> |
20 |
> My main point is that the developer profile has FEATURES=test, and also |
21 |
> arch testers and developers run with FEATURES=test. Being able to |
22 |
> quickly rebuild gcc, glibc and others is a win. |
23 |
|
24 |
Yes, I'm agreeing with you. I'd like these off by default too. We need a |
25 |
standard way of enabling them however. USE="test-dev" or something. I |
26 |
complain about this about once a year or so. ;) Maybe I should just do it. |
27 |
|
28 |
In the meantime: |
29 |
|
30 |
echo -e 'sys-libs/glibc test\nsys-devel/gcc test' \ |
31 |
>> /etc/portage/profile/package.use.mask |
32 |
|
33 |
> I'm trying to understand the problem better - do you know what causes |
34 |
> those test failures? I don't expect a "complete" answer because that'd |
35 |
> probably be a half of actually fixing the failures. |
36 |
|
37 |
The GCC testsuite isn't designed to pass. It's designed to be a |
38 |
regression test. Check before and after you apply a patch, make sure you |
39 |
don't cock things up. From http://gcc.gnu.org/install/test.html: "It is |
40 |
normal for some tests to report unexpected failures. At the current time the |
41 |
testing harness does not allow fine grained control over whether or not a test |
42 |
is expected to fail." Look at http://gcc.gnu.org/buildstat.html and you'll |
43 |
see this in practice. |
44 |
|
45 |
One thing I know of that causes a bunch of failures is the fact that we |
46 |
enable -Wformat, -Wformat-security, and -Wtrampolines by default. Any |
47 |
additional output during a test = fail. I patched these recently for 4.5 |
48 |
though so they shouldn't be a problem going forward. |
49 |
|
50 |
|
51 |
-- |
52 |
fonts, gcc-porting, it makes no sense how it makes no sense |
53 |
toolchain, wxwidgets but i'll take it free anytime |
54 |
@ gentoo.org EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 |