W dniu 07.08.2018 o 15:12, Florian Weimer pisze:
> On 08/06/2018 09:58 PM, Marcin Juszkiewicz wrote:
>> From what I remember there is no architecture supported by Fedora
>> without Valgrind support. We got rid of s390 (32bit) and risc-v does not
>> count yet.
>
> valgrind support is not
On 08/06/2018 09:58 PM, Marcin Juszkiewicz wrote:
From what I remember there is no architecture supported by Fedora
without Valgrind support. We got rid of s390 (32bit) and risc-v does not
count yet.
valgrind support is not monotonic because architectures evolve. If we
move the architecture
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 architecture. For example,
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}, but it
On Sun, 2018-08-05 at 22:13 +0200, 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,
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 of
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
13 matches
Mail list logo
