Re: Did check 0.15.x in rawhide break packages' test suites?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Aug 3, 2020 at 8:32 PM Jerry James <loganjerry@xxxxxxxxx> wrote:
>
> On Sun, Aug 2, 2020 at 11:27 AM Jerry James <loganjerry@xxxxxxxxx> wrote:
> > You can point the finger of blame at least partly at me for this.
> > Version 0.15.0 of check introduced the use of
> > __attribute__((printf....)) to check the arguments to some of the
> > calls.  However, upstream didn't do it right, with the result that gcc
> > warned on pretty much every use of the check macros.  I submitted a
> > patch upstream to fix that, which upstream applied and included in
> > version 0.15.1.  That patch, however, broke other things, such as the
> > ability to call fail_if() with only one argument.
> >
> > I've been working on another patch to fix *that*.  It's not too hard
> > to do for gcc, which makes __VA_OPT__ available to the C compiler, but
> > not so easy for the Microsoft compiler.  I'll attach what I have so
> > far.  Comments or suggestions on how to make it better are much
> > appreciated.  I would like to submit something upstream by tomorrow.
> > If upstream likes the idea, I'll do another build of check that
> > includes the patch.
>
> Upstream went with a simpler fix.  It seems that the fail_* macros are
> deprecated anyway (your upstreams should switch to using ck_assert*
> calls instead), so they just added an extra NULL argument to the end.
> That will make GCC complain about too many arguments for the format
> string in the case that more than one argument is passed, but will fix
> the breakage when only one argument is passed.
>
> I will add upstream's commit to the our package and rebuild.

Thanks! It looks like the packages which are using those macros in
their test suites now build correctly.
They'll get resubmitted by my "resubmit this if the F33FTBFS issue was
caused by a transient issue" script soon. :)

Fabio
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux