>
> valgrind support is not monotonic because architectures evolve. If we
> move the architecture baseline, we could well lose valgrind support
> again. This is true if we moved i686 from SSE2 to AVX2 (clearly
> hypothetical) or s390x from zEC12 to z13 (much less so).
> So I think %{valgr
baseline, we could well lose valgrind support
again. This is true if we moved i686 from SSE2 to AVX2 (clearly
hypothetical) or s390x from zEC12 to z13 (much less so).
So I think %{valgrind_arches} clearly has its place going forward.
Thanks,
Florian
On Mon, Aug 06, 2018 at 09:58:50PM +0200, Marcin Juszkiewicz wrote:
> W dniu 05.08.2018 o 16:36, Jeff Johnson pisze:
> > So you are recommending using 14 lines (with comments) of spec file
> > goop that uses 2 %ifarch build section tests in order to set/unset a
> > macro.
> >
> > There's further
On Sun, Aug 5, 2018 at 5:52 PM, Jeff Johnson wrote:> Try
>
> ...
> %check
> %ifarch ppc64 ppc64p7
You no longer need ppc64p7 as it's been killed off as of F-26
> exit 0
> %endif
> ...
>
> My comments apply to the rest of what you appear to be proposing everywhere.
>
W dniu 05.08.2018 o 16:36, Jeff Johnson pisze:
> So you are recommending using 14 lines (with comments) of spec file
> goop that uses 2 %ifarch build section tests in order to set/unset a
> macro.
>
> There's further baggage in spec files needed to add a BR, pass an
> option to configure, add
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 archi
On 08/05/2018 01:13 PM, Florian Weimer wrote:
On 08/05/2018 09:48 PM, Samuel Sieb wrote:
What am I missing here? Why can't this be put in RPM macros? Then
when the situation changes in the future, there's only one place to
change.
There already is such a macro, %{valgrind_arches
ready 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 run
On 08/05/2018 09:48 PM, Samuel Sieb wrote:
What am I missing here? Why can't this be put in RPM macros? Then when
the situation changes in the future, there's only one place to change.
There already is such a macro, %{valgrind_arches}, but it may not
accurately reflect the suitability
What am I missing here? Why can't this be put in RPM macros? Then when
the situation changes in the future, there's only one place to change.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to
Try
...
%check
%ifarch ppc64 ppc64p7
exit 0
%endif
...
My comments apply to the rest of what you appear to be proposing everywhere.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to
On 08/05/2018 04:36 PM, Jeff Johnson wrote:
Your 14 line example will suffer a similar fate if valgrind is fixed to run on
ppc64, or ppc64 aliases start to proliferate.
But in general, valgrind works on ppc64. Only the package-specific test
fails there.
Florian
Yuck.
So you are recommending using 14 lines (with comments) of spec file goop that
uses 2 %ifarch build section tests in order to set/unset a macro.
There's further baggage in spec files needed to add a BR, pass an option to
configure, add libraries to link, etc
You are in the wrong
in the
%{valgrind_arches} macro provided by redhat-rpm-config.
%{valgrind_arches} is always safe to use if you do not run valgrind
during build, but only need valgrind-devel because it accurately
reflects the availability of these packages.
If you run valgrind during build (BuildRequires: valgrind), you may
14 matches
Mail list logo
