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 <[EMAIL PROTECTED]> "I have no strong feelings one way or the other." -- Neutral President -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
