Hi Russ, On Monday 27 February 2012 15:28:51 Russ Allbery wrote: > Even with valgrind, personally I'd just list a specific set of > architectures on which valgrind is required, even if you also > opportunistically test for its existence. There's no reason to allow > *not* running valgrind tests on i386 and amd64.
It makes perfect sense for complete (working) test suits. I had an experience with valgrind only recently when upstream introduced yet-to-be completed tests which are failing everywhere so far. I'm already ignoring tests failure using override override_dh_auto_test: -dh_auto_test In which case it makes perfect sense not to take the risk of FTBFS on some architectures for the sake of testing which is not even useful yet. Another package I was recently testing on GNU Hurd where some tests were failing (even though the package is working). So again I had to ignore post-build test(s) failure. Testing still useful to me when I read build logs, but I'm very reluctant to introduce a potential failure point with dependency more strict than necessary. While I'm with you and I fully share the desire not to allow skipping tests on i386 or amd64, I think risk of FTBFS outweighs it. You see, When I build the package on my amd64 host I will likely to notice if something goes wrong but my concern is more about architectures I have no access to. I'm not yet in habit of reading all build logs from all architectures upon package upload when the build was successful. And it appears to me that if tests failure is already pretty much ignored is would be acceptable to make tests optional with weak build dependency. Regards, Dmitry. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201202271628.51099.only...@member.fsf.org