A Mennucc <[EMAIL PROTECTED]> writes:
>> So far, I'm not aware of any regressions
>> yet. I am aware that an updated ffmpeg could introduce regression.
>> Therefore I rely that Sam will bump the SONAME of the libraries when he
>> updates an incompatible version of ffmpeg in debian.
>
> (disclaime
[Executive summary: This discussion is about mplayer using an embedded
copy of libavcodec instead of using the shared one from Debian]
On Wed, Nov 01, 2006 at 12:24:24AM +0100, A Mennucc wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> BTW: I have been assuming that Moritz is report
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Reinhard Tartler ha scritto:
> xine is able to build against an out of tree ffmpeg. This is what the
> current xine in etch is doing.
(I was aware of this; I hope I made it clear in previous emails )
> So far, I'm not aware of any regressions
> yet.
On Sun, Nov 05, 2006 at 03:23:31PM +0100, Diego Biurrun wrote:
> Sorry if I was sounding aggressive, this was not my intention.
I apologise too if you felt hurt by me sounding like you were lying.
> Anyway, the confusion seems to have been cleared - good.
Sure. :)
Cheers,
--
.''`. Aurélien
On Sun, Nov 05, 2006 at 02:58:25PM +0100, Aurélien GÉRÔME wrote:
> On Sun, Nov 05, 2006 at 01:30:08PM +0100, Diego Biurrun wrote:
> > On Sun, Nov 05, 2006 at 12:33:07PM +0100, Aurélien GÉRÔME wrote:
> > > It just happens that I have a lot of H.264-encoded videos which
> > > will *not* run adequatel
On Sun, Nov 05, 2006 at 01:30:08PM +0100, Diego Biurrun wrote:
> On Sun, Nov 05, 2006 at 12:33:07PM +0100, Aurélien GÉRÔME wrote:
> > It just happens that I have a lot of H.264-encoded videos which
> > will *not* run adequately on the hardware you name above. We *may*
> > not have the same videos..
On Sun, Nov 05, 2006 at 12:33:07PM +0100, Aurélien GÉRÔME wrote:
> On Sun, Nov 05, 2006 at 11:52:48AM +0100, Diego Biurrun wrote:
> > On Sat, Nov 04, 2006 at 12:31:26AM +0100, Aurélien GÉRÔME wrote:
> > > This is a false argument. Come one please, do not attempt to tell me
> > > that you can decent
On Sun, Nov 05, 2006 at 11:52:48AM +0100, Diego Biurrun wrote:
> On Sat, Nov 04, 2006 at 12:31:26AM +0100, Aurélien GÉRÔME wrote:
> > This is a false argument. Come one please, do not attempt to tell me
> > that you can decently play a H.264-encoded video on a non-GHz machine
> > even with SIMD ins
On Wed, Nov 01, 2006 at 12:05:46AM +0100, Moritz Muehlenhoff wrote:
> A Mennucc wrote:
> > So I think that
> > [O] is not worth the effort: we ruin MPlayer (for sure) for hope of a
> > (not sure) benefit in security.
>
> I don't buy the argument of a completely crippled MPlayer. E.g. the
> libavco
On Sat, Nov 04, 2006 at 12:31:26AM +0100, Aurélien GÉRÔME wrote:
> On Fri, Nov 03, 2006 at 11:34:37PM +0100, Diego Biurrun wrote:
> > That benchmark was done on x86. But let's face it, it's the
> > architecture that counts. Mind that I am writing this from a PPC, which
> > is my main machine..
>
On Wed, Nov 01, 2006 at 12:24:24AM +0100, A Mennucc wrote:
> Now I really need to hear the opinion of the xine and ffmpeg Debian
> people (and also of gstreamer and any other package using ffmpeg) about [N]
xine is able to build against an out of tree ffmpeg. This is what the
current xine in etch
On Fri, Nov 03, 2006 at 11:34:37PM +0100, Diego Biurrun wrote:
> That benchmark was done on x86. But let's face it, it's the
> architecture that counts. Mind that I am writing this from a PPC, which
> is my main machine..
I disagree, amd64 would be the architecture which counts and amd64
has eno
On Tue, Oct 31, 2006 at 10:43:17PM +0100, Aurélien GÉRÔME wrote:
>
> On Tue, Oct 31, 2006 at 07:46:01PM +0100, Diego Biurrun wrote:
> > Removing the embedded copies of FFmpeg libraries from MPlayer is a bad
> > idea.
>
> For the workload on the security team and the overall quality of Debian
> (a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
BTW: I have been assuming that Moritz is reporting the consensus of the
whole security team , and not only his personal opinion... is it so?
whereas Joey reported the opinion of the release people (that was not
opposite to [A])
I personally may embra
A Mennucc wrote:
> The overhead [O] may simply be not worth the (supposed) future benefit
> for security.
It's not theoretical, but a genuine problem that affects us here and
today. We've had the whole mess for CVE-2005-4048, we're currently
encountering it with CVE-2006-4799/CVE-2006-4800 and we'
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
hi
I would like to add my 2¢ (although Dario's email pretty much says it all)
Here are 3 possible scenarios:
[N] The safest way to linking MPlayer with dynamical FFmpeg would be :
each time there is a MPlayer release, Diego provides us with the corr
Hi Diego,
On Tue, Oct 31, 2006 at 07:46:01PM +0100, Diego Biurrun wrote:
> Removing the embedded copies of FFmpeg libraries from MPlayer is a bad
> idea.
For the workload on the security team and the overall quality of Debian
(a single source package for whatever produced binary packages),
I stro
On Sun, Oct 29, 2006 at 12:53:37AM +0200, Moritz Muehlenhoff wrote:
> On Sat, Oct 28, 2006 at 01:08:09PM -0400, Joey Hess wrote:
> > Moritz Muehlenhoff wrote:
> > >
> > > > The testing security team tracks probably hundreds of possibly security
> > > > relevant code copies in data/embedded-code-co
On Sat, Oct 28, 2006 at 01:08:09PM -0400, Joey Hess wrote:
> Moritz Muehlenhoff wrote:
> > severity 395252 serious
> > thanks
> >
> > > The testing security team tracks probably hundreds of possibly security
> > > relevant code copies in data/embedded-code-copies in their svn repo. As
> > > long a
Moritz Muehlenhoff wrote:
> severity 395252 serious
> thanks
>
> > The testing security team tracks probably hundreds of possibly security
> > relevant code copies in data/embedded-code-copies in their svn repo. As
> > long as the security teams know about code copies, they can deal with
> > updat
severity 395252 serious
thanks
> The testing security team tracks probably hundreds of possibly security
> relevant code copies in data/embedded-code-copies in their svn repo. As
> long as the security teams know about code copies, they can deal with
> updates due to them.
No, we have already way
severity 395252 important
thanks
The testing security team tracks probably hundreds of possibly security
relevant code copies in data/embedded-code-copies in their svn repo. As
long as the security teams know about code copies, they can deal with
updates due to them. Getting rid of embedded code c
22 matches
Mail list logo
