So I see. At any rate, you can find the full logs at https://buildd.debian.org/status/logs.php?pkg=sdformat&ver=2.0.0-2&suite=sid
Also, FWIW, one unusual aspect of the autobuilders' environment that sometimes breaks tests is running with a "home directory" of /sbuild-nonexistent; see, e.g., https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746624 Thanks, Aaron Jose Luis Rivero <jriv...@osrfoundation.org> writes: > I've never seen this before in sdformat upstream project or our own > building farms. The fact that only odd tests are failing is because > the even ones are just checkers of the output of the test run > before. So the conclusion is: all of them are returning a timeout. > > May I have access to the building log? What command is exactly being > run during the test phase? > > Thanks! > > On 05/07/2014 10:17 PM, Aaron M. Ucko wrote: >> Source: sdformat >> Version: 2.0.0-1 >> Severity: serious >> Justification: fails to build from source >> >> Automated builds of sdformat have all been encountering test timeouts, >> in a distinctive pattern: >> >> The following tests FAILED: >> 1 - INTEGRATION_audio (Timeout) >> 3 - INTEGRATION_cfm_damping_implicit_spring_damper (Timeout) >> 5 - INTEGRATION_fixed_joint_reduction (Timeout) >> 7 - INTEGRATION_joint_axis_frame (Timeout) >> 9 - INTEGRATION_provide_feedback (Timeout) >> 11 - PERFORMANCE_parser_urdf (Timeout) >> 13 - UNIT_SDF_TEST (Timeout) >> 15 - UNIT_Console_TEST (Timeout) >> 19 - UNIT_parser_urdf_TEST (Timeout) >> >> It's not clear why, but I do see that the tests were always running in >> parallel; could they somehow interfere with each other? At any rate, >> please do take a look. >> >> Thanks! -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers