| Summary: | app-crypt/mit-krb5 fails tests | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Hans de Graaff <graaff> |
| Component: | New packages | Assignee: | Gentoo Kerberos Maintainers <kerberos> |
| Status: | CONFIRMED --- | ||
| Severity: | minor | CC: | kingjon3377, letharion, nikoli, paolo.pedroni, patrick, perfinion |
| Priority: | High | Keywords: | TESTFAILURE |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
build.log
emerge --info build.log-1.9 testlog (krb5-1.9) the first build log, -1.9.1 another first build log, -1.9.1 the second build log, -1.9.1 my emerge --info build.log for test failure of mit-krb5-1.12.1-r2 emerge --info |
||
|
Description
Hans de Graaff
2011-02-11 11:17:56 UTC
Created attachment 262111 [details]
build.log
Created attachment 262113 [details]
emerge --info
I can't reproduce this and code looks OK. What version of tcl, dejagnu and expect? (In reply to comment #3) > I can't reproduce this and code looks OK. > > What version of tcl, dejagnu and expect? tcl: 8.5.8-r1 dejagnu: 1.4.4-r1 expect: 5.44.1.15 Bleh, still no go. Before spending too much time on it, can you please check with mit-krb5-1.9-r1 as well? Testing framework changed between version 1.8 and 1.9. I would rather not debug this (rare?) hiccup if we are going to drop it in a few weeks time. app-crypt/mit-krb-1.9-r1 also fails for me. Created attachment 262327 [details]
build.log-1.9
> See testlog for details, or re-run with -v flag Please attach the testlog (/var/tmp/portage/app-crypt/mit-krb5-1.9-r1/work/krb5-1.9/src/lib/krb5/krb/testlog) > checking python2.3/Python.h usability... yes > checking python2.3/Python.h presence... yes > checking for python2.3/Python.h... yes > checking python2.5/Python.h usability... no > checking python2.5/Python.h presence... no > checking for python2.5/Python.h... no > checking for main in -lpython2.3... yes Also, try without python-2.3 installed if possible. Created attachment 262511 [details]
testlog (krb5-1.9)
(In reply to comment #8) > Also, try without python-2.3 installed if possible. Good catch, no clue why these files from 2005 were still on my system. Gone now, but no difference. See attached testlog. I'm seeing the same test failure with 1.9.1. When the test run fails, can you run the resolv command at the command prompt? $ /var/tmp/portage/app-crypt/mit-krb5-1.9.1/work/krb5-1.9.1/src/tests/resolve/resolve You should get "Resolve library appears to have passed the test" as the last line of output. If not, fiddle with /etc/hosts until you do and re-run the tests. Please do not forget ipv6 entries as well if it is turned on, i.e. in /etc/hosts I am looking for something like: 127.0.0.1 test.example.com localhost ::1 test.example.com localhost Also, hostname command should also be giving test.example.com as output. Thank you. (In reply to comment #12) > When the test run fails, can you run the resolv command at the command prompt? Hostname: graaff Host address: 80.101.101.38 FQDN: graaff.xs4all.nl Resolve library appears to have passed the test > 127.0.0.1 test.example.com localhost > ::1 test.example.com localhost > > Also, hostname command should also be giving test.example.com as output. Thank > you. Are you saying that I need to add this to /etc/hosts to get tests to pass? Or that something similar would get tests to fail? This is all I have in /etc/hosts: 127.0.0.1 localhost ::1 localhost (In reply to comment #13) > This is all I have in /etc/hosts: Please try with 127.0.0.1 graaff.xs4all.nl localhost ::1 graaff.xs4all.nl localhost and make sure hostname output is graaff.xs4all.nl Thanks. (In reply to comment #14) > (In reply to comment #13) > > This is all I have in /etc/hosts: > > Please try with > > 127.0.0.1 graaff.xs4all.nl localhost > ::1 graaff.xs4all.nl localhost > > and make sure hostname output is graaff.xs4all.nl > > Thanks. That seems to work, but it also seems broken to me, since that hostname should not be associated with the loopback device. With this in place I still get a failure further on: Running ./krb-standalone/sample.exp ... Running ./krb-standalone/simple.exp ... ERROR: sim_server failed to start ERROR: error in simple.exp : spawn id exp15 not open (In reply to comment #15) > That seems to work, but it also seems broken to me, since that hostname should > not be associated with the loopback device. Aye. That was just a quick and dirty check to see if the problem is really with name resolution. You should revert the changes in /etc/hosts and check your name lookups. Please make sure everything is resolvable and matches. Kerberos is picky in this regard. > Running ./krb-standalone/sample.exp ... > Running ./krb-standalone/simple.exp ... > ERROR: sim_server failed to start > ERROR: error in simple.exp > : spawn id exp15 not open Buildlog and testlog please. archtester documents # eselect python list Available Python interpreters: [1] python2.7 * [2] python3.1 yields the first archtester documents # eselect python list Available Python interpreters: [1] python2.7 [2] python3.1 * yields the 2nd. Created attachment 279267 [details]
the first build log, -1.9.1
Created attachment 279271 [details]
another first build log, -1.9.1
Ended up running the emerge again with seemingly same settings (python 2.7 selected) and it gave this slightly better run. Couldn't find a testlog that gave errors.
Created attachment 279277 [details]
the second build log, -1.9.1
Created attachment 279279 [details]
my emerge --info
*** Bug 373803 has been marked as a duplicate of this bug. *** *** Bug 386725 has been marked as a duplicate of this bug. *** *** Bug 438094 has been marked as a duplicate of this bug. *** Created attachment 382270 [details]
build.log for test failure of mit-krb5-1.12.1-r2
Created attachment 382272 [details]
emerge --info
also:
# qlist -Iv dejagnu
dev-util/dejagnu-1.4.4-r3
|