On Sun, 2018-08-05 at 15:55 -0700, Samuel Sieb wrote:
> On 08/05/2018 01:13 PM, Florian Weimer wrote:
> > There already is such a macro, %{valgrind_arches}, but it may not
> > accurately reflect the suitability of the run-time behavior of valgrind
> > on a particular architecture. For example, the undefinedness tracking
> > might not be sufficiently accurate for the testsuite of a specific
> > package, so running the testsuite under valgrind gives false positives.
>
> So the original post is only to be used for specific exceptional cases?
Yes, Florian was just being very thorough.
We noticed packages disabled valgrind support on different
architectures for 2 different reasons.
It was disabled based on which architectures the package thought
valgrind was available for. If you just need to enable/disable valgrind
support because of this then please just use the %{valgrind_arches}
macro instead of hardcoding an architecture list in your package. The
macro will be updated whenever valgrind gets support for a new
architecture (or if an architecture is not longer completely supported,
it will be removed from this macro).
Secondly there might be a bug in valgrind on a particular architecture
that is triggered by something specific in the package. In that case
please use the construct Florian suggested to enable support based on
the %{valgrind_arches} macro with some package specific exception for
that particular architecture. And please file a bug against valgrind,
so it might get fixed.
Cheers,
Mark
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/QLI3DS7ACNRL4ZB5XTA5KO4MICKISTPB/
