[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#402772: marked as done (downgrade mplayer bug 395252 (for including mplayer in etch))

Your message dated Sat, 16 Dec 2006 00:44:59 -0800
with message-id <20061216084459.GA12727@mauritius.dodds.net>
and subject line Bug#402772: bug 402772: downgrade mplayer bug 395252 (for including mplayer in etch)
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)
--- Begin Message --- 
Package: tech-ctte
Severity: important

hi


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 by ~the same people); Aurélien GÉRÔME and
Moritz Muehlenhoff ask that the mplayer package be dynamically linked to
the libraries in the Debian package ffmpeg (instead of statically
linking with the copy shipped in the star of MPlayer); they consider
this bug a RC bug.

I do not think that this bug is "serious" & RC; and, moreover,
I do not think that MPlayer deserves to be kept out of Etch on
the basis of bug 395252.

Please tell me if you back me up in downgrading this bug (at least for
the Etch release).

Let me also afore mention that,even though I do not agree with the
 bug 395252 being RC, I still tried to satisfy the requests
 in that bug: see
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=395252;msg=152
Since I did not receive the needed help,
after the freeze  I tried to compromise, in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=395252;msg=157
but  my proposal was not accepted.

 --

Let me report some facts from bug 395252.

Early in the discussion, Joey Hess reports in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=395252;msg=12
"How is mplayer different than the 200 or so other items listed in
embedded-code-copies? Other than only getting through incoming now.
I discussed this on #debian-release and people seemed to think it wasn't
and this shouldn't be RC."

Diego Biurrun and other people of MPlayer team say that dynamical
linking is an experimental feature, and that indeed it disables some
features of MPlayer (mainly postprocessing); moreover, the dyn.lin.
MPlayer is slower.

Loïc Minier reports the case of gst-ffmpeg in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=395252;msg=59
"gst-ffmpeg upstream is maintaining a ffmpeg mirror, and has a complex
procedure to update to newer snapshots.... I currently see no way to
achieve building  of gst-ffmpeg [with dyn.lin. of ffmepg] in a sane and
maintainable way, and it seems we are very far from that. Very very far."

To that, Moritz Muehlenhoff answers
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=395252;msg=134
"gst-ffmpeg is indeed an exceptional case, which we'll support for Etch.
(That's also why there is no RC bug on it)."

I fail to see why gst-ffmpeg can be an exceptional case, and MPlayer cannot.


 ---

I did put quite some effort in it (& MPlayer as a whole), both in coding
and in "politics"; but this is becoming too frustrating!

Please help.


a.

Attachment: signature.asc
Description: OpenPGP digital signature


--- End Message ---
--- Begin Message --- 
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 (informal) discussion in
> >> #d-release, and the opinion was that this bug 295252 was not RC at all.

> > However, the release team is also almost certainly going to defer to the
> > security team's judgement as to whether a given package is supportable in a
> > stable release, since it's the security team who ultimately has to do the
> > supporting.

> > So in that sense, yes, it would be RC if the security team says it's RC.

> hi Steve

> I think that we are reaching an agreement

> Moritz said in
> http://lists.debian.org/debian-devel/2006/12/msg00322.html
> that he thinks this bug should be RC, but that an exception should be
> made for Etch

> If everybody agrees, may someone in release team add a etch-ignore to
> that bug?

Andi and I are agreed that this is a suitable solution given the evident
approval of the security team.  I'm tagging bug #395252 etch-ignore with
this mail (which means solving this *is* regarded as release critical for
lenny), which means that, AFAICS, there is no longer a matter for the TC to
rule on so I'm also closing that bug.

Cheers,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/

--- End Message ---
Reply to: