Re: chromium-browser from experimental has included h.264 by default?
On Wed, May 12, 2010 at 00:29:02 (CEST), Stefano Zacchiroli wrote:
> On Tue, May 11, 2010 at 08:55:17PM +0200, Moritz Muehlenhoff wrote:
>> > Surely not. Chromium ships a *private* copy of ffmpeg, more precisely, a
>> > fork of ffmpeg called ffmpeg-mt. Debian does not include ffmpeg-mt
>> > because of bug #575600 (tagged wontfix). Moreover, Debian's copy of
>> > ffmpeg will always be out-of-date.
>> >
>> > I wonder why the security team hasn't vetoed this move...
>>
>> Chromium isn't meant to be released with Squeeze. We'll reevaluate for
>> Squeeze+1.
>
> Ouch, that hurts, and it's a pity: it's likely to be a good reasons for
> some desktop users to use a different Debian-based distro [1]. Now,
> there can be very good technical reasons for that, but can you please
> explain them or give pointers to where they've been discussed?
>
> AFAICT from another message in this thread, Giuseppe is working on
> compiling against system ffmpeg and not using at all the private copy of
> ffmpeg, so that shouldn't be a showstopper.
TBH, I'm very skeptical. While I'm not sure why google has decided to
choose astrange's branch/fork, I fear that there have been too many
changes to the external public API that this is not going to work out.
I'm basing this opinion on the Giuseppe's observation that Chromium does
not even compile against ffmpeg 0.5 (debian' system) ffmpeg.
It would be of course interesting to see how this works out with ffmpeg
0.6 (currently in NEW), but for totally unrelated reasons to this one, I
fear it won't be processes as well, just like mplayer.
> At worst, if that will turn out not to be possible, we can disable
> ffmpeg support (as a last resort) and still ship chromium-browser in
> Squeeze (unless of course other RC bugs will show up). So I guess the
> reason must be something else.
What I could imagine is to seperate out the ffmpeg module into a
seperate source package, and ship it in a 3rd party repository outside
of debian squeeze.
> I understand that the security team might be skeptical about security
> support, but IIRC past vetoes from the security team came from software
> with bad _history_ of security support, while in this case it would seem
> a preemptive move, isn't it?
Au contraire, most recent security patches in ffmpeg originated in some
way or an other from chromium. Granted, some where because of bugs
introduced by chromium changes themselves, but this story shows that
google takes security serious. For this reason, I think that chromium
upstream is providing excellent security support for its copy of ffmpeg!
> Anyhow, from a transparency/communication point of view, it would
> probably be better to have the package in unstable anyhow, and block it
> out of testing with an RC bug which explains why it's out, so that users
> not finding it in Squeeze will have a place ... against which bang their
> head :-)
Agreed. That approach would at least give everyone a chance to properly
document and express their opinions and concerns
--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4
Reply to: