#4565 closed enhancement (fixed)
MIT Kerberos V5 1.12
| Reported by: | Armin K | Owned by: | Pierre Labastie |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | BOOK | Version: | SVN |
| Severity: | normal | Keywords: | |
| Cc: |
Description
Change History (10)
comment:1 by , 10 years ago
comment:2 by , 10 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → assigned |
comment:3 by , 10 years ago
I have had a hard time with tests. The test harness is rather complicated, with some using dejagnu and some using custom test programs. This makes the output almost impossible to read. A lot of subdirectories in the tree have their own tests, and those are runned recursively. Two directories have tests which fail:
-one is testing the libdb2 plugin. It uses the dictionary installed for cracklib, but since that dictionary contains shell metacharacters and spaces, the test fails. If another dictionary is given, the first test passes and all the others hang... Those tests can be eliminated with a sed to Makefile in that directory.
-one is using dejagnu for testing kdb. There are some wrong assumptions about the output (xst command echo), which make about fifty tests fail. It is possible to have those tests pass with a sed to default.exp. I do not know whether it is worth it.
follow-up: 5 comment:4 by , 10 years ago
I think that if the tests take too much time and become counterproductive, better is to place a "make -k" and, eventually, some comments. The most important objective is the package, not the tests?
comment:5 by , 10 years ago
Replying to fo:
I think that if the tests take too much time and become counterproductive, better is to place a "make -k" and, eventually, some comments. The most important objective is the package, not the tests?
You are right Fernando, but in this case, what I have found is scarry: tests of the db2 database seem to fail. Since, as far as I understand (I plan to check that with upstream), this is the default database if ldap is not installed, and Kerberos may be used in sensitive environments, I cannot keep that under the carpet. OTOH, maybe the tests are not relevant or wrong. I want to check first whether those tests are better with former versions, and to check with upstream that their failure is harmless. Otherwise, I think the package should be removed from the book, or at least that the user be informed.
comment:7 by , 10 years ago
I rather think that testsuite is broken or requires some extra setup. I'd rather go with "not working testsuite" or "make -k check" and a note about expected failures rather than checking. Last version I ran testsuite was 1.10.x version because I was updating the package and it seemed to work, I don't know what happened.
comment:8 by , 10 years ago
I have tested with 1.11.4, 1.10.7 and 1.10.1, with same results. Failures in krb test are due to the therminal width setting: the test expects some output, but if the output is longer than a line, there is an unexpected carriage return. So the tests might pass if the hostname and the source directory paths are short. I am amazed you have not seen the db2 test error (either hanging if there is no /usr/share/dict/words, or erroring if ther is a dictionary including shell metacharacters). Maybe it is not tested if you build with ldap support. I think I'll commit tomorrow, using what I have found up to now.
Now 1.12.1