Re: Dropping GStreamer 0.8 for etch

[Moritz Muehlenhoff <jmm@inutil.org>]

Josselin Mouette wrote:
> By hiding behind upstream, you're simply refusing to fix the problem.
> The patch is a hack that is only guaranteed to work on a Debian system,
> and upstream will refuse it until it is done in a proper way. This is
> not how things work. Forwarding fixes upstream is important but it
> doesn't come before fixing the Debian bug.
>
>> > As the situation is very similar in mplayer, mplayer is considered
>> > RC-buggy by the security team. There was an exception for
>> > gstreamer-ffmpeg because it was considered too difficult to fix, but I
>> > don't think this is justified and this should be considered
>> > release-critical as well.
>> 
>>  Again, nothing new.  As you state yourself, this was already discussed
>>  and an exception was granted.  Beside, you miss the important point
>>  that gst-ffmpeg heavily patches (read: "replaces") the ffmpeg build
>>  system, wihle mplayer has a close-to-vanilla ffmpeg tree.
>
> The exception was granted because of this assumption, which is *entirely
> wrong*, as gst-ffmpeg ships a vanilla ffmpeg tree. It took me less than
> one hour to figure it out and to build a working package with the Debian
> ffmpeg library.
>
>>  "Dropping GStreamer 0.8 for etch" is not "building gst-ffmpeg against
>>  Debian's ffmpeg"; any of these changes can be achieved in whatever
>>  order, these are orthogonal, even if both would help security support
>>  (in a different way).  As I'm not considering building gst-ffmpeg
>>  against ffmpeg for etch, I kindly suggest we let this subthread die or
>>  be continued in the upstream bug report where it would be more useful.
>
> As the security people are the ones being really affected, I would like
> to have Moritz' input on this matter. Are you ready to grant an
> exception to gstreamer-ffmpeg and not to mplayer while the situation of
> both packages is strictly identical?

When preparing DSA-992 for ffmpeg I looked at other packages embedding
libavcodec and IIRC gst-ffmpeg's copy was forked at that time. If it's
technically feasible to fix gst-ffmpeg 0.10 to link dynamically against
etch's libavcodec that would be of course the preferred solution, especially
if it should bring in new bugfixes/features (that's what I understood about your
previous comment about H264?)
However, we're rather late in the release cycle and if Loic as one of
the GNOME maintainers thinks that adapting gst-ffmpeg is too risky or
not possible w/o regressions in the depending apps that would be understandable.
OTOH you're among the GNOME maintainers as well and should have the full
picture as well, so I'm a bit confused. I'd conclude to:
1. Let's all avoid flames (the latest followups have become too hostile)
   and concentrate on an Etch release, which kicks ass.
2. If the GNOME maintainers come to an agreement that linking dynamically
   is possible it would be _much_ appreciated, if not we need to bite the
   bullet.

And for mplayer; it provides dynamic linking out of the box and it's not
an important infrastructure package like gstreamer, so the above does not
apply.

Cheers,
        Moritz