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: