[tor-relays] Compiling tor- on Raspberry Pi

Lance Hathaway qhltx at yahoo.com
Tue Apr 29 03:21:03 UTC 2014

Hash: SHA512

On 25/04/2014 7:34 AM, Nick Mathewson wrote:
> On Fri, Apr 25, 2014 at 5:17 AM, Oliver Baumann
> <baumanno at 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-' 
>>> 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, and try 
> once it comes out.  (Today, I hope!)
> cheers,

Thanks Nick, 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.

Version: GnuPG v2.0.22 (MingW32)


More information about the tor-relays mailing list