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

Re: Dropping GStreamer 0.8 for etch

On Thu, Dec 07, 2006, Josselin Mouette wrote:
> I don't think this justifies the extra burden on the security team, and
> the bugs in some codecs that are fixed in the Debian ffmpeg package.
> Given the growing number of h.264 videos out there, it doesn't make much
> sense to ship a video player that can't read them, especially when it
> can be so easily fixed.

 It's nice that you're concerned by this state of fact, but this is
 nothing new, and was already discussed multiple times.  I actually
 already discussed this since months with 1) Debian users 2) upstream 3)
 the ffmpeg maintainer 4) the security team.
   If you truly want to unlock this situation, subscribe to the upstream
 bug on the subject, and update your patch to be acceptable upstream.

> 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.

 "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.

Loïc Minier <lool@dooz.org>
 "I have no strong feelings one way or the other." -- Neutral President

Reply to: