-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On 25/04/2014 7:34 AM, Nick Mathewson wrote:
On Fri, Apr 25, 2014 at 5:17 AM, Oliver Baumann baumanno@cip.ifi.lmu.de wrote:
On 04/24/14, Lance Hathaway wrote:
Apologies if this would be better addressed in a different list...
I know there are a couple of people here who are working on making the Raspberry Pi a good option for running Tor--and the work is appreciated! Gordon Morehouse has built binary pickages for the Pi, but I wanted to try compiling it myself (for good practice, mostly).
I followed the directions for compiling from source on a Debian-based system, but the compile fails with the following:
config/parse_bridge_line: FAIL ../src/test/test_config.c:373: a.b.c.d was supposed to fail, but it didn't. FAIL ../src/test/test_config.c:374: assert(!bridge_line) [parse_bridge_line FAILED]
...some log lines skipped for brevity...
1/201 TESTS FAILED. (1 skipped) make[1]: *** [test] Error 1 make[1]: Leaving directory `/home/pi/debian-packages/tor-0.2.5.3-alpha/build' dh_auto_test: make -j1 test returned exit code 2 make: *** [build] Error 29 dpkg-buildpackage: error: debian/rules build gave error exit status 2 debuild: fatal error at line 1357: dpkg-buildpackage -rfakeroot -D -us -uc failed
I confess, I haven't the slightest clue what to do with this. Have I overlooked something stupid? I don't want to open a "bug" unless it's an honest-to-goodness bug (developers have better things to do with their time than chase down "bugs" which are actually "user errors"), but I don't have the knowledge to say whether this is a bug or not...
Any thoughts?
I think this is a symptom of bug #10801 and isn't your fault at all. It can happen when you run the unit tests somewhere with a captive portal that returns an answer for a DNS lookup of "a.b.c.d".
(In fact, I found #10801 thanks to a coffee shop where the unit tests didn't pass.)
You can safely ignore this test failure in 0.2.5.3-alpha, and try 0.2.5.4-alpha once it comes out. (Today, I hope!)
cheers,
Thanks Nick, 0.2.5.4-alpha compiled cleanly and without errors.
For the record, I think you were right on the "captive portal" idea. My local DNS server is set to use OpenDNS resolvers from long ago, and it will resolve any invalid DNS queries to their search engine. Even now, I can resolve "a.b.c.d." to a real IP, which probably shouldn't happen. I'll need to fix that behavior so that I get proper NXDOMAIN responses in future.
-Lance