-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
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?
-Lance
On 04/24/14, Lance Hathaway wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
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?
-Lance -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32)
iQIcBAEBCgAGBQJTWW95AAoJEECmBqfoBgXnbVcQALl69M5KuGTfpUH/nsl6hxCu RwB+u5kothwRIPoJblHdEa7m00sWJxUc8HlHfczgjIYkC1gob+vgIDiMR6skAc2t RdSaCYuKWTh6RVTXUAb4UNd3GdvTu/QW/5NsUYDFlTT4QIxg7W2OEOirC4x9bNei gspV+TyOBdJbrTWmVoBFh8YPbpVeY1R5rwARjv7BOhkDCAle3N4vh+S3LvUNr3hk bUimllKSK7fht7bFyesiCrPB1wUxEazAwD7iIDCj6XmVRM57Wu9TV48RO+LLWEB5 qdKuTvN4MyqFbCiuBQXWU5Ps+IEOwoLSVzkQDvtdXhA1WvQmt8gVavXlRlZ+vWIi bEnJFxLMTqcwmC7RRk5blKr73/fBllaEumTpV4TfO3wRDwCKvtKLum9Z6wyV6g8n iY1WoJIThAiN6UM/nohKiecwM/L5e0gwEbkIxYLiCDGwzR3/QAvU84dv4a3EvWcy ptVZgcSQ3B4g55FOlTSJTasBG/rkCIm0Kdi6D7qXAUdm+ylSn/9eMcealSBwk38F Cfm/5P0bMAaKyGugY9VvoMPku8rsQgcimuUY8jH+8WgUxlUcZoL0fYSZ9hiVZ+m4 zW+MiA8Ct2MSzx5GNDDjdBYs7TqOE/MywkSIoxzgy/h0fhAaC3Vm5+NpkI8Z7MUD /1MdDUHCawEZk8KHt7ev =GIPd -----END PGP SIGNATURE----- _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Hi Lance, the reason you are seeing this seems to be a failing software-test which ships natively with tor. I'm not experienced enough to comment on the nature of this behaviour, for what I see it might as well be a bug.
Anyway, on my RasPi running Raspbian I had no problems compiling tor-0.2.5.3-alpha with this: debuild -rfakeroot -uc -us Try it and maybe report back!
All the best, baumanno
On Fri, Apr 25, 2014 at 5:17 AM, Oliver Baumann baumanno@cip.ifi.lmu.de wrote:
On 04/24/14, Lance Hathaway wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
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,
-----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
tor-relays@lists.torproject.org
-
Lance Hathaway -
Nick Mathewson -
Oliver Baumann