On Sat, Dec 16, 2006 at 11:03:50AM +0100, A Mennucc wrote:
[preface: the following is just for the sake of discussion - I am
satisfied by how we reached an agreement]
Steve Langasek ha scritto:
On Fri, Dec 15, 2006 at 01:02:55PM +0100, A Mennucc wrote:
ffmpeg is developed inside MPlayer ;
Steve Langasek ha scritto:
Um, I said this would be my conclusion if it were my decision *personally*.
I'm not the maintainer of any of these packages, so it's not. :)
sorry, I failed to understand the meaning of personally
a.
signature.asc
Description: OpenPGP digital signature
tags 395252 etch-ignore
thanks
On Fri, Dec 15, 2006 at 11:58:10AM +0100, A Mennucc wrote:
Steve Langasek ha scritto:
On Wed, Dec 13, 2006 at 09:24:05AM +0100, A Mennucc wrote:
Just for the record: the release team had already expressed his view
(in a sense): in Oct, there was already a
On Fri, Dec 15, 2006 at 01:02:55PM +0100, A Mennucc wrote:
lets come to today
today, the ffmpeg inside Debian is 6 months older then the one in
MPlayer; for that reason , DynLEF fails . When I tried it,
I also tried 'make -k' , to see if there were few failures that I could
fix; but the
[preface: the following is just for the sake of discussion - I am
satisfied by how we reached an agreement]
Steve Langasek ha scritto:
On Fri, Dec 15, 2006 at 01:02:55PM +0100, A Mennucc wrote:
ffmpeg is developed inside MPlayer ; for that reason, they (correctly)
feel free to improve it in
On Sat, Dec 16, 2006, A Mennucc wrote:
we delete ffmpeg from Debian stable,
since it is not really a library yet
We can also keep ffmpeg (the binary), without its lib. :)
so we also delete ffmpeg from inside:
libxine1 , used in
xine-lib builds against Debian's ffmpeg AFAICT, *not*
I am sorry, there were many misunderstanding
(my argument was not clear enough - and it was too verbose)
Let me be a bit more precise. I repeat my (hypothetical) reasoning.
---
Steve said:
if it were my
decision *personally*, I would likely judge mplayer/ffmpeg too immature to
be included
On Sat, Dec 16, 2006, A Mennucc wrote:
BTW: after etch is release, you (AFAICR) are willing
to update gst-ffmpeg to use DynLEF (as Josselin was proposing).
Yes, but only because it was merged upstream, and with the additional
maintenance costs it involves. BTW, an upstream developer already
On Wed, Dec 13, 2006 at 09:24:05AM +0100, A Mennucc wrote:
Just for the record: the release team had already expressed his view
(in a sense): in Oct, there was already a (informal) discussion in
#d-release, and the opinion was that this bug 295252 was not RC at all.
However, the release team
Steve Langasek ha scritto:
On Wed, Dec 13, 2006 at 09:24:05AM +0100, A Mennucc wrote:
Just for the record: the release team had already expressed his view
(in a sense): in Oct, there was already a (informal) discussion in
#d-release, and the opinion was that this bug 295252 was not RC at
On Tue, Dec 12, 2006 at 09:17:10PM +0100, A Mennucc wrote:
This question is urgent, in the sense that I would like your help about
bug 395252, that as so far stopped mplayer from entering in Etch.
Brief summary of bug: MPlayer contains an embedded copy of FFmpeg
(indeed, they are developed
Steve Langasek ha scritto:
There is a middle ground here, which is mplayer statically linking
against the common ffmpeg package; I think that would be a reasonable
compromise, and I'd like to know if there are reasons this too isn't
achievable for etch. There may be known reasons, of course
On Wed, Dec 13, 2006 at 08:01:58AM +0100, Andreas Barth wrote:
Actually, I think we should refuse dealing with the issue now, because
according to Don (wearing [EMAIL PROTECTED] hat) the decision whether a bug is
RC or not is done by the release team, not the maintainer - and the
release team
Anthony Towns ha scritto:
Uploading dynamically linked ffmpeg/mplayer packages to experimental for
inclusion in unstable in the near future seems like a sensible thing to
do too.
I actually tried to do that.
Even though I did not think 395252 should be a RC bug, nonetheless I
tried to
Anthony Towns ha scritto:
Moritz has expressed significant concern that the security team won't
be able to manage that support in the bug log, though according to [0]
thinks an exception is appropriate:
[snip]
If that's the case, I think that alone resolves the problem; and I think
that
15 matches
Mail list logo
