-
Notifications
You must be signed in to change notification settings - Fork 3.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
make verify fails with some dns test in 2.0.21 #38
Comments
This is a known problem with some of the DNS unit tests in libevent 2.0 and earlier: They require particular behavior on the part of the local DNS resolver. The fix in Libevent 2.1 is not to run these particular tests by default. |
@nmathewson Thanks for your reply. if it is possible, could give me a more detailed explanation about the needed particular behaviour for the local DNS resolver? I would know what specific changes are needed in local DNS resolver for pass the test. |
From the looks of it, your resolver isn't answering the PTR requests for the address 127.0.0.1. Those unit tests expect that the resolver will tell it some answer (ideally "localhost"). Personally, I would recommend instead that you skip this test or ignore the results if it isn't passing; it was IMO a mistake to have libevent |
Thanks for spotting this. The test has now been disabled. |
You say this is disabled, yet I still see the same failure in 2.0.22. |
One of the problems I noticed with anything client-dns test related is that we rely on our systems to be online and have a proper recursive setup somewhere that doesn't have any filtering. I have been working on a test-plan to alleviate this problem. 2.1 is a good place for this to happen. |
@benlaurie I think he's talking about in his project. |
AFAIU 2.1 doesn't have this issue, can we close this or we want this fixed in 2.0? |
Closing this one, if somebody thinks that this must be fixed in 2.0, please reopen! |
Running make verify I get this in a Centos 6.3 machine:
The text was updated successfully, but these errors were encountered: