It is time to really delve into this. I do not think that this bug is "serious". (I have actually the feeling that the severity for this bug is "wishlist". ) Here are some reasonings:
1) It is true that the debian-policy asks for dynamic compilation, whenever possible; but the MPlayer team deprecate dynamic linking of ffmpeg: dynamic linking is an experimental feature, it breaks many postprocessing options; so it is not really supported. What you are asking for is not a feature currently sported by MPlayer; as such, your request is "severity:wishlist". If you want dynamic linking in MPlayer, you are free to work on it until it works flawlessly, and send me a patch. 2) Never AFAIK was there a "release goal" of "all packages must compile with external ffmpeg" 3) You never opened a serious bug against gst-ffmpeg although gst-ffmpeg is linked with an internal static ffmpeg. And I do not think that you are entitled to claim that severity is "serious". - You are not in the release team. The only person in the release team that ever expressed an opinion in this bug thread is Joey Hess http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=395252;msg=12 and he said that this bug should not be RC - You are not in the development team of MPlayer, and AFAIK you never tried to build/test/improve dynamical linked mplayer (for sure, you did not help me doing that) - You have never brought up a detailed explanation to your claims. Your original claim is "This is hindering the security team and the overall quality of Debian." This is a nice principle to state; but "nice principle" does not immediatly entail "RC" ; quite the opposite, according (1) (2) (3) Indeed, your principle may be applied to many packages and to many situations. For example, we have many web browser around, and there have been a lot of web-related security problems lately; but I did not hear you (or any other) go shouting "hey! we have too many web browser around! This is hindering the security team! Lets kick konqueror out of Debian!" --- Anyway, for sake of discussion, lets suppose that "static ffmpeg is hindering the security team". Suppose in 6months there will be a security problem in ffmpeg: then the MPlayer/FFmpeg team will provide a patch; then the security team will need to apply it. What package will provide the most troubles? Well, the package that is shipping the oldest and more ad-hoc-modified static ffmpeg ... and that is gst-ffmpeg (closely followed by the quite old ffmpeg in Debian ffmpeg). But you (and Muehlenhoff) do not consider that gst-ffmpeg "hinders the security team". Moritz Muehlenhoff writes in: 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)." (Also, go reread http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=395252;msg=139 it is quite surprising). According to your actions, it seems that the only ffmpeg-related package that "hinders the security team" is MPlayer ! This is nonsensical: of all packages in Debian in this very moment, MPlayer contains the most up-to-date ffmpeg (and then the lest prone to bugs) and the one who will get most help from the MPlayer/FFmpeg. ---- Aurélien GÉRÔME wrote: > Sure, I got that. Fine, the shame on me is my punishment for having > wanted to get a compromise. :) Compromise? I am the guy that does try to find compromises. I am the guy who spent many years to find a compromise to let MPlayer into Debian - in the end, I even agreed to remove mencoder "for fear of patent problems", although most of the encoding stuff is in ffmpeg and that is already in Debian. When you posted this bug, I did not agree with you, but I proposed different options to address it; and discussed with the upstream team (that does not approve dynamical linking); and I prepared new packages for mplayer, xine, and ffmpeg; and I benchmarked it; and tested it on different codecs. All this, even if I do not agree with your definition of severity. That is my spirit of "compromise". Your behaviour is "heh, gst-ffmpeg is fine, but lets bug mplayer guy forever, regardless of any reasoning put forth by him, Joey Hess, MPlayer team, etc etc?". When did you ever tried to find a compromise? I tried to set "severity:important". But your idea of compromise between "severity:serious" and "severity:wishlist" is "severity:serious". Your (repeated) example of compromise is "echo severity serious | mail [EMAIL PROTECTED]". You call that a compromise? ---- Aurélien GÉRÔME wrote: > Sorry Andrea, this is really RC (as I always said), but this is also > RC for etch (as I was told on #debian-release). Quite peculiar. 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." Moreover, A. Barth wrote you: > Andreas Barth wrote: >> > etch-ignore is only to be set by the release team, or upon special >> > authorisation. I do not see that as backing your claims. --- > Cheers, I see nothing to cheer about a.
signature.asc
Description: OpenPGP digital signature
