[tor-relays] Compiling tor-0.2.5.3-alpha on Raspberry Pi

[Lance Hathaway]

-----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 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-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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQIcBAEBCgAGBQJTXxqcAAoJEECmBqfoBgXnfxwP/3yqfB/Sm8Nepd+T41Zybw3q
fIYl5GQJ/ZylTcG5tQIUsbsNHsau3g14oIsSO0RtGHWOSQJVQfK/9FhYSPbdHtT8
qXsmkGu2lcB0CnAD/cIRaub9uGnqqh1zJsO9g5F3wGv0+cZmLItRT2E3ZC8EYpCc
7bvPx+ZP5YQQh+6f3FSkLhOb+gaym3vf3aLlUA4lwpuDXMuWXQ3zXeRHEfDKUUxD
MMMNhtg/96zj7vfFOFt50TY+W8FkpaSUOs2+yAkCYUL333UCvlJOcWKTVv1irCi5
Yaysxt0wMuZpLf12V10vu3flwovpplcTmhgU+yUCQt1QYmBuvWFCgz6lsaShGkrj
lfo02w3Dv8M+r2nM4MEwK/MeIxKoBUDueBkziO8/IT6MvEh31BctyR4b3o8n5GDS
9WR9HkqYvk3RR1At6I08jJjGYwuxRvFeVpmeQaz91kuN1wDFp01y3sZOFlLQ3exn
Ez2/Ol1HahPRvJn/eHnoiN9LDeXtcJnyBEd1mt799P4+vcst9ichYM6OTzDrnUXq
wRmxfnyRk9qcx4j7IZwvnrZ1ZVnLtbKFLdHy6+qpXUYPHTuSeSAN5snX17TilH//
VF+2xzxFjDSGDDdi8JSAGP/KDelnX79i4XTdlc/zYlBhdATAvIOfWMilGwDSUxwk
VgpejP0KB7RW/MseXEQH
=DuWI
-----END PGP SIGNATURE-----