On Thu 2017-01-26 10:47:44 -0500, Daniel Kahn Gillmor wrote: > I note that having a test suite contact the network (as the two > failing tests appear to want to do) is also probably not a great idea. > It means that the test suite will fail on a build daemon that doesn't > have network access, and also that it may intermittently fail based on > whether the remote network service is available.
one way to resolve this in a principled fashion without skipping the tests is to have the test suite set up a mini-keyserver on the loopback (this is really just an http server that responds correctly to the specific queries that it might receive) and configure schleuder to use it during the testing. Another note related to this: i see that you've added dirmngr to the Build-Depends:, but i think that it's only necessary if the builder is running the test suite. In some circumstances, the builder doesn't need or want to run the tests, so they should know that they don't need to install testing-only dependencies to build the package. This is most often accomplished by setting "DEB_BUILD_OPTIONS=nocheck" You can make these build-dependencies conditional by using the "nocheck" build profile, see: https://wiki.debian.org/BuildProfileSpec?highlight=%28nocheck%29 so instead of having: Build-Depends: foo, dirmgnr, bar you'd have: Build-Depends: foo, dirmngr <!nocheck>, bar You can add this same nocheck build profile designation to all the b-d entries that are only needed for the test itself, not just dirmngr :) hth, --dkg
signature.asc
Description: PGP signature
_______________________________________________ Pkg-ruby-extras-maintainers mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-ruby-extras-maintainers
