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
