guix-devel
[Top][All Lists]
Advanced

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

Re: 01/01: gnu: gstreamer: Skip failing test on 32-bit systems.


From: Mark H Weaver
Subject: Re: 01/01: gnu: gstreamer: Skip failing test on 32-bit systems.
Date: Sun, 16 Jun 2019 17:31:08 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)

Hi Marius,

Marius Bakke <address@hidden> writes:

> Mark H Weaver <address@hidden> writes:
>
>> address@hidden writes:
>>
>>> mbakke pushed a commit to branch staging
>>> in repository guix.
>>>
>>> commit 2a9d89afb6fb869dd2bdf1e9f710f487786930fc
>>> Author: Marius Bakke <address@hidden>
>>> Date:   Thu Jun 13 14:08:32 2019 +0200
>>>
>>>     gnu: gstreamer: Skip failing test on 32-bit systems.
>>>     
>>>     * gnu/packages/gstreamer.scm (gstreamer)[arguments]: When building for a
>>>     32-bit system, add #:phases.
>> [...]
>>> +       ,@(if (not (target-64bit?))
>>> +           ;; Skip test that fails on 32-bit systems:
>>> +           ;; 
>>> <https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/316>.
>>> +           `(#:phases (modify-phases %standard-phases
>>> +                        (add-before 'check 'disable-gstbufferpool-test
>>> +                          (lambda _
>>> +                            (substitute* "tests/check/Makefile"
>>> +                              (("^[[:blank:]]+gst/gstbufferpool.*$")
>>> +                               ""))
>>> +                              #t))))
>>> +           '())))
>>
>> This might be sweeping a critical bug under the rug.  Does
>>
>>   Unexpected critical/warning: gst_buffer_resize_range:
>>     assertion 'bufmax >= bufoffs + offset + size' failed
>>
>> really sound like something we can safely ignore?
>
> I think you are right to be concerned.  I found the upstream commit that
> introduced the problem.  See
> <https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/316#note_176773>.

Thanks for checking.

> Do you have a preference for reverting the faulty commits, or going back
> to 1.14.5?

It depends on the nature of the faulty commit, whether other later
commits somehow depend on it, and whether other potential security holes
were fixed since 1.14.5.  Maybe use 1.14.5, possibly with cherry-picked
fixes applied as patches?  I'm not sure, and I don't have time to
investigate right now, but I trust your judgement to choose the best
available option.

   Thank you!
      Mark



reply via email to

[Prev in Thread] Current Thread [Next in Thread]