| View previous topic :: View next topic |
| What do you do about glibc failing it's tests? |
| I do not run the tests |
|
84% |
[ 11 ] |
| I discard the test results if they do not look worse than the currently installed glibc |
|
15% |
[ 2 ] |
| I do not install a glibc which fails it's tests |
|
0% |
[ 0 ] |
|
| Total Votes : 13 |
|
| Author |
Message |
sera
Retired Dev
Joined: 29 Feb 2008
Posts: 1017
Location: CET
|
 Posted: Mon Nov 01, 2010 4:53 pm Post subject: Glibc and failing tests |
 |
|
With every update of glibc I wonder how to best go about failing tests.
There are reasons for a test to fail besides a broken glibc and this is where the difficulty comes in. For peace of mind I would love to see them succeed.
The current set of failed tests for me looks almost the same as in bug 270997. Also using amd64 here.
So how to estimate the severeness of them. The bug doesn't mention it and trying to search the Internet for good information proves to be difficult. Maybe I'm just taking the wrong approach.
Sometimes I think it would be nice to have a gentoo specific page with glibc test result for different archs/profiles for glibc's in the tree so a user could better estimate how borked his toolchain might be. Well the same is of course of interest for other packages as well. For such a page a little bonus could be some comments on the failing tests.
So what do you do if glibc fails it's test? My answer would be compare with previous results and check bugzilla. If not obviously worse I go ahead and install it. |
|
| Back to top |
|
 |
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54308
Location: 56N 3W
|
| Posted: Mon Nov 01, 2010 6:45 pm Post subject: |
|
|
sera,
Tests fail for three reasons:-
1. They are supposed to fail
2. The test suit has not been updated to keep up with the revised code
3. The package is broken.
With something as critical as glibc, I tend to install it anyway as
a) I'm not first
b) there will be an outcry all over Google if glibc breaks
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
sera
Retired Dev
Joined: 29 Feb 2008
Posts: 1017
Location: CET
|
| Posted: Tue Nov 02, 2010 2:40 pm Post subject: |
|
|
| NeddySeagoon wrote: | sera,
Tests fail for three reasons:-
1. They are supposed to fail |
In case of glibc they are supposed to be marked (ignore) or in case of gcc as expected failures and as unexpected passes, right?
| NeddySeagoon wrote: | | 2. The test suit has not been updated to keep up with the revised code |
This and kernel, compiler, libc packages being out of sync are the main cause so I suspect. However the bug I linked to is now older than a year. Tests like this don't serve any purpose. Interestingly there is an x86 example completing the tests successfully. Could the tests not actually point out an issue? For instance the IO deadlock is something only seen on amd64. Sure here are most likely other things to blame. But what I want to say is issues in glibc can crop up in all sorts of places. An other example is --enable-async-renderer in evas where I (and maybe only I) had issues. I still don't know what was to blame. It went away at some point. Some of the details are in the "Enlightenment is coming" thread.
| NeddySeagoon wrote: | | 3. The package is broken. |
I hope it's not but how should I tell.
| NeddySeagoon wrote: |
With something as critical as glibc, I tend to install it anyway as
a) I'm not first
b) there will be an outcry all over Google if glibc breaks |
This strategy does not address local issues like a corrupted filesystem due to power outage or filesystem bugs for instance. For Gentoo packages I hope( and actually know) at the time they are going stable point a) and b) are fulfilled.
Anyway, thanks for your answer. |
|
| Back to top |
|
|
|
Gentoo Chat
