Bug#395252: ignore bug 395252 'mplayer embeds ffmpeg' for lenny
On Thu, Jun 19, 2008 at 09:50:24AM +0200, Fabian Greffrath wrote: (1) Ffmpeg should finally decide about a stable API, or at least one that is stable for more than two weeks. It is commonly believed myth that FFmpeg does not have a stable API, but a myth nonetheless. Diego -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#395252: ignore bug 395252 'mplayer embeds ffmpeg' for lenny
Reinhard Tartler schrieb: Since mplayer includes an exact copy of ffmpeg by using an 'svn:external' on the ffmpeg svn, it makes sense to build shared library packages out of that source. [...] Well, sorry Reinhard, but building such a complex set of libraries from the source code which is embedded in a (kind of) random application sounds rathers insane to me. You know how tricky it can be to package the ffmpeg libs even from a clean dedicted tarball. I suggest two different measures instead, but I fear they will be ignored upstream once again: (1) Ffmpeg should finally decide about a stable API, or at least one that is stable for more than two weeks. Releases will also be highly appreciated. If (for whatever reason) formal releases are impossible, at least define something like 'milestones', meaning: If you want to package a rather recent version of ffmpeg, use SVN export of 2008xxyy, since it has proven to compile well and includes only few regressions. I don't know if the news section on the ffmpeg homepage is supposed to provide such recommendation or if it is only for plain information. (2) Mplayer developers, how about building against the *public* ffmpeg API, so that distributors can link your application against the libraries without being forced to make use of the embedded code that you ship? I mean, this isn't a Debian specific issue and you're calling your current tarball a Release Candidate... A Mennucc: You do not see the many emails I sent to ffmpeg-free mantainers, almost all of them went unanswered (but for one). I can provide you a complete list, if you wish. Have you sent those via private mail? To be honest, I've never read an attempt of yours to improve the ffmpeg situation on the pkg-multimedia mailing list. I have to admit that I am in the ffmpeg team for only a few weeks now, but I am subscribed to the pkg-multimedia list as long as it exists. Cheers, Fabian -- Dipl.-Phys. Fabian Greffrath Ruhr-Universität Bochum Lehrstuhl für Energieanlagen und Energieprozesstechnik (LEAT) Universitätsstr. 150, IB 3/134 D-44780 Bochum Telefon: +49 (0)234 / 32-26334 Fax: +49 (0)234 / 32-14227 E-Mail: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#395252: ignore bug 395252 'mplayer embeds ffmpeg' for lenny
Fabian Greffrath [EMAIL PROTECTED] writes: Reinhard Tartler schrieb: Since mplayer includes an exact copy of ffmpeg by using an 'svn:external' on the ffmpeg svn, it makes sense to build shared library packages out of that source. [...] Well, sorry Reinhard, but building such a complex set of libraries from the source code which is embedded in a (kind of) random application sounds rathers insane to me. You know how tricky it can be to package the ffmpeg libs even from a clean dedicted tarball. I know that it is tricky, but I still think that for the problem we are facing, this is an acceptable solution. YMMV of course. I suggest two different measures instead, but I fear they will be ignored upstream once again: (1) Ffmpeg should finally decide about a stable API, or at least one that is stable for more than two weeks. Releases will also be highly appreciated. From the last remarks I have heared from upstream is that they want to wait this year's GOC and integrate the results from that. After that a release could indeed happen, depending on the available manpower, of course. If (for whatever reason) formal releases are impossible, at least define something like 'milestones', meaning: If you want to package a rather recent version of ffmpeg, use SVN export of 2008xxyy, since it has proven to compile well and includes only few regressions. I don't know if the news section on the ffmpeg homepage is supposed to provide such recommendation or if it is only for plain information. Please see http://ffmpeg.mplayerhq.hu/faq.html#SEC2 and #SEC3. Short: there is not enough interest in maintaining stable releases. This means additional efford for: - tracking bugs - fixing bugs - write release notes etc. (2) Mplayer developers, how about building against the *public* ffmpeg API, so that distributors can link your application against the libraries without being forced to make use of the embedded code that you ship? I mean, this isn't a Debian specific issue and you're calling your current tarball a Release Candidate... FFMpeg and Mplayer developers have a rather large overlap. I cannot imagine that you can convince them to restrict themselves to the public ffmpeg api, but good luck with that! A Mennucc: You do not see the many emails I sent to ffmpeg-free mantainers, almost all of them went unanswered (but for one). I can provide you a complete list, if you wish. Yes, please do provide such a list. I currently don't understand what you are referring to. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#395252: ignore bug 395252 'mplayer embeds ffmpeg' for lenny
Reinhard Tartler schrieb: I know that it is tricky, but I still think that for the problem we are facing, this is an acceptable solution. YMMV of course. Fine, but how about all the other packages that depend on ffmpeg, like gstreamer, vlc and xine. They do also ship embedded copies of ffmpeg source code. I fear these packages could suffer from the decision to gear our ffmpeg library packages to mplayer releases. From the last remarks I have heared from upstream is that they want to wait this year's GOC and integrate the results from that. After that a release could indeed happen, depending on the available manpower, of course. I'll have to see it to believe it. :) Short: there is not enough interest in maintaining stable releases. This means additional efford for: - tracking bugs - fixing bugs - write release notes etc. Come on, thousands of even smaller software projects face these problems regularly and nevertheless get releases going. FFMpeg and Mplayer developers have a rather large overlap. I cannot imagine that you can convince them to restrict themselves to the public ffmpeg api, but good luck with that! Then they shouldn't distinguish between these two projects and refrain from releasing the libraries separately - at least if mplayer does not build with the separately relased libraries. BTW, how large is the overlap of ffmpeg developers with vlc or xine? Cheers, Fabian -- Dipl.-Phys. Fabian Greffrath Ruhr-Universität Bochum Lehrstuhl für Energieanlagen und Energieprozesstechnik (LEAT) Universitätsstr. 150, IB 3/134 D-44780 Bochum Telefon: +49 (0)234 / 32-26334 Fax: +49 (0)234 / 32-14227 E-Mail: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#395252: ignore bug 395252 'mplayer embeds ffmpeg' for lenny
On Thu, Jun 19, 2008 at 01:35:49PM +0200, Fabian Greffrath wrote: Reinhard Tartler schrieb: FFMpeg and Mplayer developers have a rather large overlap. BTW, how large is the overlap of ffmpeg developers with vlc or xine? Practically zero. Diego signature.asc Description: Digital signature
Bug#395252: ignore bug 395252 'mplayer embeds ffmpeg' for lenny
Fabian Greffrath [EMAIL PROTECTED] writes: Reinhard Tartler schrieb: I know that it is tricky, but I still think that for the problem we are facing, this is an acceptable solution. YMMV of course. Fine, but how about all the other packages that depend on ffmpeg, like gstreamer, vlc and xine. They do also ship embedded copies of ffmpeg source code. I fear these packages could suffer from the decision to gear our ffmpeg library packages to mplayer releases. They would not suffer from that because mplayer embeds an unmodified, clean copy of ffmpeg. So they are using exactly the same source. I already elaborated on the case that depending packages need a newer version of ffmpeg. Short: there is not enough interest in maintaining stable releases. This means additional efford for: - tracking bugs - fixing bugs - write release notes etc. Come on, thousands of even smaller software projects face these problems regularly and nevertheless get releases going. There have been quite some people offering help on doing that on the mailing list, but everyone then vanished from the surface. Feel free to start a new attempt. FFMpeg and Mplayer developers have a rather large overlap. I cannot imagine that you can convince them to restrict themselves to the public ffmpeg api, but good luck with that! Then they shouldn't distinguish between these two projects and refrain from releasing the libraries separately - at least if mplayer does not build with the separately relased libraries. I'm very hesitant making recommendation what ffmpeg or mplayer deverlopers should do or not without actually being involved with that projects. They are successful at writing good software. BTW, how large is the overlap of ffmpeg developers with vlc or xine? Close to non-existant AFAIK. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#395252: ignore bug 395252 'mplayer embeds ffmpeg' for lenny
Reinhard Tartler schrieb: I'm very hesitant making recommendation what ffmpeg or mplayer deverlopers should do or not without actually being involved with that projects. They are successful at writing good software. Good objection, sorry. ;) -- Dipl.-Phys. Fabian Greffrath Ruhr-Universität Bochum Lehrstuhl für Energieanlagen und Energieprozesstechnik (LEAT) Universitätsstr. 150, IB 3/134 D-44780 Bochum Telefon: +49 (0)234 / 32-26334 Fax: +49 (0)234 / 32-14227 E-Mail: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#395252: ignore bug 395252 'mplayer embeds ffmpeg' for lenny
Note that I am upstream for both MPlayer and FFmpeg. On Thu, Jun 19, 2008 at 01:35:49PM +0200, Fabian Greffrath wrote: Reinhard Tartler schrieb: I know that it is tricky, but I still think that for the problem we are facing, this is an acceptable solution. YMMV of course. Fine, but how about all the other packages that depend on ffmpeg, like gstreamer, vlc and xine. They do also ship embedded copies of ffmpeg source code. I fear these packages could suffer from the decision to gear our ffmpeg library packages to mplayer releases. All packages already suffer from being tied to a specific FFmpeg release. Building against another FFmpeg version is a rather big change from the upstream releases. From the last remarks I have heared from upstream is that they want to wait this year's GOC and integrate the results from that. After that a release could indeed happen, depending on the available manpower, of course. Short: there is not enough interest in maintaining stable releases. This means additional efford for: - tracking bugs - fixing bugs - write release notes etc. Come on, thousands of even smaller software projects face these problems regularly and nevertheless get releases going. The problem is that many people request releases, but nobody is willing to step up to help with releases. Obviously none of the current FFmpeg developers has a problem with the way things are handled right now and there are always more interesting things than fixing other people's issues... FFMpeg and Mplayer developers have a rather large overlap. I cannot imagine that you can convince them to restrict themselves to the public ffmpeg api, but good luck with that! Then they shouldn't distinguish between these two projects While there is a large overlap, the projects are most definitely not the same. Also, I think it is always a bad idea to tell other projects what they should or should not do. If I voiced my opinion about what the Debian project should do with the same amount of conviction, I'm sure you guys would take me out back and beat me up ;-) Diego -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#395252: ignore bug 395252 'mplayer embeds ffmpeg' for lenny
Diego Biurrun schrieb: Also, I think it is always a bad idea to tell other projects what they should or should not do. If I voiced my opinion about what the Debian project should do with the same amount of conviction, I'm sure you guys would take me out back and beat me up ;-) Again, sorry for my smart-ass behaviour. :) -- Dipl.-Phys. Fabian Greffrath Ruhr-Universität Bochum Lehrstuhl für Energieanlagen und Energieprozesstechnik (LEAT) Universitätsstr. 150, IB 3/134 D-44780 Bochum Telefon: +49 (0)234 / 32-26334 Fax: +49 (0)234 / 32-14227 E-Mail: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#395252: mplayer+ffmpeg, and some progress, Re: Bug#395252: ignore bug 395252 'mplayer embeds ffmpeg' for lenny
On Wed, Jun 18, 2008 at 04:24:18PM +0200, Reinhard Tartler wrote: Since mplayer includes an exact copy of ffmpeg by using an 'svn:external' on the ffmpeg svn, it makes sense to build shared library packages out of that source. hi Reinhard, I did build such a package ~1 month ago; the package source name is mplayer+ffmpeg , and it is a combination of mplayer.orig.tar.gz + ffmpeg-free.orig.tar.gz + all mplayer debian/ + all ffmpeg debian/ + extra quilt (it uses the latest features of dpkg-source (3.0 quilt) , it is quite neat). So this mplayer+ffmpeg package is a merge , containing both packages, in two separate subtrees. Since the subtrees are separate, this means that it is reasonably easy to transition for we mplayerffmpeg developers: to start with, each one of us can just work in the subtree where we know how stuff work; then we refine and polish to taste. Pros: the package mplayer+ffmpeg package compiles and builds all expected binaries. What it does: copy fffmpeg code into mplayer cd into ffmpeg subtree, apply ffmpeg quilt debian patches, compile ffmpeg-free binaries cd into mplayer subtree, apply mplayer debian patches, compile mplayer binary Cons: at that time, I did not find out a way to link mplayer to ffmpeg (but see next section). The reason why I was despairing, is that the following sequence failed to link. apply ffmpeg quilt debian patches into ffmpeg subtree copy fffmpeg code into mplayer cd into ffmpeg subtree, compile ffmpeg-free binaries cd into mplayer subtree, apply mplayer debian patches, compile mplayer binary So my best understanding was that, somehow, one of the ffmpeg quilt debian patches was changing some important code , and that rendered it incompatible with mplayer. But really I could not understand what was wrong. But I did a great progress. After I received the bad news, I went to the drawing table once again, started everything from scratch once again, and step by step I created a new set of patches, and this time I could link a version of mplayer to the ffmpeg libraries. This is very preliminary, I dont understand why it works now and it did not work before, I did not even have time to test if this mplayer can play most video and audio OK. If it works, I will also need to post some patches for ffmpeg-free : indeed , the ffmpeg *-dev files do not contain currently some .h and .c files that mplayer needs. I will post more info as I find some time to test the compiled binary and the resulting package. (sorry I have to be brief, I am busy with Real Life Work Moving to a New House (tm) in these days) -- My package mplayer+ffmpeg remains though an interesting object, that we may explore for lenny+1 ; now that I have also some new possibly working better patches, I will improve it, and I will upload it to experimental. a. -- Andrea Mennucc The EULA sounds like it was written by a team of lawyers who want to tell me what I can't do, and the GPL sounds like it was written by a human being who wants me to know what I can do. Anonymous,http://www.securityfocus.com/columnists/420 signature.asc Description: Digital signature
Bug#395252: ignore bug 395252 'mplayer embeds ffmpeg' for lenny
hi On Tue, Jun 17, 2008 at 10:28:27PM +0100, Neil McGovern wrote: I'm afraid I can't accede to your request. This bug has been open since 25 Oct 2006. The etch-ignore tag was added 16 Dec 2006, where it was explicitly stated that it's RC for lenny. I pinged the bug on 28 Mar 2008, to again state that it's RC for lenny. May you please explain which part of the debian-policy, or which release goal, it is violating? I'm concerned as to why there as been seemingly no progress in over a year to resolving this issue. This is all explained in the long email I sent; anyway, let me summarize again. Up to a 2008-05-19 , the version of ffmpeg-free in unstable was totally incompatible with mplayer. The new version of ffmpeg-free is based on a compatible code, but the quilt patches disable a symbol that is needed to link to mplayer. a. -- Andrea Mennucc The EULA sounds like it was written by a team of lawyers who want to tell me what I can't do, and the GPL sounds like it was written by a human being who wants me to know what I can do. Anonymous,http://www.securityfocus.com/columnists/420 signature.asc Description: Digital signature
Bug#395252: ignore bug 395252 'mplayer embeds ffmpeg' for lenny
On Wed, Jun 18, 2008 at 11:10:21AM +0200, A Mennucc wrote: hi On Tue, Jun 17, 2008 at 10:28:27PM +0100, Neil McGovern wrote: I'm afraid I can't accede to your request. This bug has been open since 25 Oct 2006. The etch-ignore tag was added 16 Dec 2006, where it was explicitly stated that it's RC for lenny. I pinged the bug on 28 Mar 2008, to again state that it's RC for lenny. May you please explain which part of the debian-policy, or which release goal, it is violating? Neither, it's the RC policy which carries more weight than a RG: http://release.debian.org/lenny/rc_policy.txt 5a) Packages in the archive must not be so buggy or out of date that we refuse to support them. The security team has confirmed multiple times that this is no longer supportable. I'm concerned as to why there as been seemingly no progress in over a year to resolving this issue. This is all explained in the long email I sent; anyway, let me summarize again. Up to a 2008-05-19 , the version of ffmpeg-free in unstable was totally incompatible with mplayer. The new version of ffmpeg-free is based on a compatible code, but the quilt patches disable a symbol that is needed to link to mplayer. And that was the case since 16 Dec 2006? Why was this not brought up sooner, and why has there been zero effort made into resolving this issue, as far as we can see? Neil -- pixie hermanr_: I never studied german pixie I can just read some of it because it makes sense Tolimar . o O ( There is stuff Ganneff writes, which makes sense? ) signature.asc Description: Digital signature
Bug#395252: ignore bug 395252 'mplayer embeds ffmpeg' for lenny
On Wed, Jun 18, 2008 at 10:29:17AM +0100, Neil McGovern wrote: On Wed, Jun 18, 2008 at 11:10:21AM +0200, A Mennucc wrote: And that was the case since 16 Dec 2006? yes. Read ahead. Why was this not brought up sooner, and why has there been zero effort made into resolving this issue, as far as we can see? You don't see all that has happened. You do not see the many emails I sent to ffmpeg-free mantainers, almost all of them went unanswered (but for one). I can provide you a complete list, if you wish. The other thing you fail to see is that the ffmpeg transition was announced on d-devel-announce on 1st July 2007 (yes, that is not a typo!) and is still going on, according to http://packages.qa.debian.org/f/ffmpeg-free.html You do not see the weekends I spent in the last 3 months trying to link mplayer to ffmpeg-free in Debian. Another thing you fail to see is that, each time there was a security bug in MPlayer, I prepared a corrected source in a 48h time max, signed it, and sent an email to the security team telling them where to retrieve the new source. In some cases, I even prepared the correct source before a security alert was issued by CVE. In some cases, moreover, the security team took 1 month (!) to then forward my source into stable-security. Yet another thing you fail to see is that I care for my packages a lot: mplayer is 1191 in the popcon list, and yet I manage to keep its bug count at a reasonable ~40; I regularly upload new versions, and fix as many bugs as I can each time. If I had known in advance that all my time was lost for nothing, I would have gone collecting daises in sunlight instead. a. -- Andrea Mennucc The EULA sounds like it was written by a team of lawyers who want to tell me what I can't do, and the GPL sounds like it was written by a human being who wants me to know what I can do. Anonymous,http://www.securityfocus.com/columnists/420 signature.asc Description: Digital signature
Bug#395252: ignore bug 395252 'mplayer embeds ffmpeg' for lenny
On Wed, Jun 18, 2008 at 12:29:45PM +0200, A Mennucc wrote: On Wed, Jun 18, 2008 at 10:29:17AM +0100, Neil McGovern wrote: On Wed, Jun 18, 2008 at 11:10:21AM +0200, A Mennucc wrote: And that was the case since 16 Dec 2006? yes. Read ahead. Why was this not brought up sooner, and why has there been zero effort made into resolving this issue, as far as we can see? You don't see all that has happened. Yes, I don't. You didn't update the bug, or tell us what was going on. We can't read minds. You do not see the many emails I sent to ffmpeg-free mantainers, almost all of them went unanswered (but for one). I can provide you a complete list, if you wish. The only one I see is http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2007-September/000408.html, and that's for a different issue. I also find it fairly rich that you complain at a lack of answers, and yet don't reply to pings to a BR asking for an update. The other thing you fail to see is that the ffmpeg transition was announced on d-devel-announce on 1st July 2007 (yes, that is not a typo!) and is still going on, according to http://packages.qa.debian.org/f/ffmpeg-free.html You seem to be confused, these aren't the same transition. The one mentioned in 2007 transitioned on 2007-07-05, five days after the mail. Perhaps the fact that the source package name has changed in the last year is causing an issue for you? You do not see the weekends I spent in the last 3 months trying to link mplayer to ffmpeg-free in Debian. This is good, but should have happened sooner. This bug has been open since Sarge was stable. Yet another thing you fail to see is that I care for my packages a lot: mplayer is 1191 in the popcon list, and yet I manage to keep its bug count at a reasonable ~40; I regularly upload new versions, and fix as many bugs as I can each time. But not enough to fix a RC bug that's been open since 2006. If I had known in advance that all my time was lost for nothing, I would have gone collecting daises in sunlight instead. It doesn't have to be for nothing; Get the issue resolved, and mplayer can move back into testing. Neil -- jmtd irssiproxy appears to be crack cut with washing up powder signature.asc Description: Digital signature
Bug#395252: ignore bug 395252 'mplayer embeds ffmpeg' for lenny
On Wed, Jun 18, 2008 at 10:29:17AM +0100, Neil McGovern wrote: Neither, it's the RC policy which carries more weight than a RG: http://release.debian.org/lenny/rc_policy.txt 5a) Packages in the archive must not be so buggy or out of date that we refuse to support them. The security team has confirmed multiple times that this is no longer supportable. Your phrase no longer confirms that there is a fundamental misunderstanding in this point. The package 'mplayer' is not 'so buggy', it has 40 bugs, and that is average. The only RC bug that 'mplayer' has is 395252. This bug says mplayer requires too much security maintainance work due to embedded ffmpeg copy. But this too much security work was claimed even before etch was released, and is a claim that had and still has no supporting facts. Indeed 'mplayer' had 3 security updates so far in Etch. No one of those security updates was fixed by patching code in the ffmpeg library. So this whole bug 395252 is based on an apriori assumption; moreover this assumption was proved wrong by facts. Summarizing, you are deciding that mplayer is too buggy to be supported because of a bug that claims that same argument. Don't you see how circular this whole reasoning is? Not to mention that, for reasons behond my comprehension, mplayer is the only package targetted by this reasoning. 1) As I said in the other email, the policy 3.8.0 now contains a paragraph [14.3] against embedded copies, that is though waived for Lenny. For some reasons, you do not accept that mplayer be given the same treatment. 2) Another point is that http://svn.debian.org/wsvn/secure-testing/data/embedded-code-copies?op=filerev=0sc=0 lists many packages which ship embedded copies. One example is mozilla/iceweasel/iceape. Iceweasel had 9 security bugs in Etch. Iceweasel has ~500 bugs (!!). So iceweasel should be kept out of Lenny, since it contains embedded copies of code and is quite buggy. But no one is ever posting this RC bug. Why? Beats me. a. -- Andrea Mennucc The EULA sounds like it was written by a team of lawyers who want to tell me what I can't do, and the GPL sounds like it was written by a human being who wants me to know what I can do. Anonymous,http://www.securityfocus.com/columnists/420 signature.asc Description: Digital signature
Bug#395252: ignore bug 395252 'mplayer embeds ffmpeg' for lenny
On Wed, Jun 18, 2008 at 12:30:33PM +0100, Neil McGovern wrote: I also find it fairly rich that you complain at a lack of answers, and yet don't reply to pings to a BR asking for an update. The reason I did not reply is that I was working to find a solution to the bug, but I did not find it. You seem to be confused, these aren't the same transition. The one mentioned in 2007 transitioned on 2007-07-05, five days after the mail. Perhaps the fact that the source package name has changed in the last year is causing an issue for you? OK, I get the point. You do not see the weekends I spent in the last 3 months trying to link mplayer to ffmpeg-free in Debian. This is good, but should have happened sooner. This bug has been open since Sarge was stable. ffmpeg-free 0.svn20080206-1 was uploaded in experimental in 2008-03-30. Before, AFAICR, a C structure in libavcoded was different, there was no hope of linking. I regularly upload new versions, and fix as many bugs as I can each time. But not enough to fix a RC bug that's been open since 2006. I fix all bugs that can reasonably be fixed. When ffmpeg in Debian was too obsolete to link to mplayer, there was nothing I could do. Since 2006, many things happened; for example, in http://bugs.debian.org/403330 I asked for a new version of ffmpeg, but 403330 was closed by the version 0.cvs20070307 that became rapidly obsolete wrt mplayer 1.0~rc2 a. -- Andrea Mennucc The EULA sounds like it was written by a team of lawyers who want to tell me what I can't do, and the GPL sounds like it was written by a human being who wants me to know what I can do. Anonymous,http://www.securityfocus.com/columnists/420 signature.asc Description: Digital signature
Bug#395252: ignore bug 395252 'mplayer embeds ffmpeg' for lenny
On Wed, Jun 18, 2008 at 12:25:33PM +, A Mennucc wrote: I fix all bugs that can reasonably be fixed. When ffmpeg in Debian was too obsolete to link to mplayer, there was nothing I could do. Since 2006, many things happened; for example, in http://bugs.debian.org/403330 I asked for a new version of ffmpeg, but 403330 was closed by the version 0.cvs20070307 that became rapidly obsolete wrt mplayer 1.0~rc2 Hint: ffmpeg in Debian is team maintained. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpVzI1ejIN7O.pgp Description: PGP signature
Bug#395252: ignore bug 395252 'mplayer embeds ffmpeg' for lenny
Pierre Habouzit [EMAIL PROTECTED] writes: On Wed, Jun 18, 2008 at 12:25:33PM +, A Mennucc wrote: I fix all bugs that can reasonably be fixed. When ffmpeg in Debian was too obsolete to link to mplayer, there was nothing I could do. Since 2006, many things happened; for example, in http://bugs.debian.org/403330 I asked for a new version of ffmpeg, but 403330 was closed by the version 0.cvs20070307 that became rapidly obsolete wrt mplayer 1.0~rc2 Hint: ffmpeg in Debian is team maintained. Indeed, and any help is more than welcome on this point. As for the current discussion mplayer embedding an copy of ffmpeg, I'd like to express an idea I had proposed previously with A Mennucc and Sam. I proposed to turn the table: Since mplayer includes an exact copy of ffmpeg by using an 'svn:external' on the ffmpeg svn, it makes sense to build shared library packages out of that source. This way mplayer could even link statically against ffmpeg (which is recommended by upstream btw) without having to go into the code duplication argument. In case of an security issue in ffmpeg, one would need to touch the mplayer source package in any case. The rest of debian packages using ffmpeg would then link against the shared version of mplayer. This has of course serious drawbacks: - the complexity of the mplayer package increases in complexity. The package needs to be extended with multiple build runs, one for the mplayer build, and then one (or even more times) for ffmpeg builds in several variants. - mplayer doesn't release that often. It might be very well possible that other packages would require a newer verison of ffmpeg that is provided by the last mplayer release. The first point probably rules out the implementation of this idea for lenny. I feel it is to late for that, but I'm neither part of the release team nor involved in mplayer maintenance, so YMMV. For the second point I see the following approaches: 1a. update mplayer to a later svn snapshot. 1b. keep the mplayer version but update the ffmpeg copy from svn 1c. keep mplayer and mplayer, but include the diff to the newer svn version of ffmpeg. 2. keep the ffmpeg package but providing updated version of the library. The second approach means of course code duplication and we should avoid that if we can. I imagine an RC bug preventing propagation to testing of the package, or keeping that package in experimental only. Having such a package available would allow experimenting and testing with a newer ffmpeg copy and help for consideration of approaches 1a to 1c. A, if you want to work on that, let's discuss this on the pkg-multimedia list, that is CC'ed with this email. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#395252: ignore bug 395252 'mplayer embeds ffmpeg' for lenny
On Wed, Jun 18, 2008 at 02:09:06PM +0200, A Mennucc wrote: On Wed, Jun 18, 2008 at 10:29:17AM +0100, Neil McGovern wrote: Neither, it's the RC policy which carries more weight than a RG: http://release.debian.org/lenny/rc_policy.txt 5a) Packages in the archive must not be so buggy or out of date that we refuse to support them. The security team has confirmed multiple times that this is no longer supportable. Your phrase no longer confirms that there is a fundamental misunderstanding in this point. The package 'mplayer' is not 'so buggy', it has 40 bugs, and that is average. The only RC bug that 'mplayer' has is 395252. This bug says mplayer requires too much security maintainance work due to embedded ffmpeg copy. But this too much security work was claimed even before etch was released, and is a claim that had and still has no supporting facts. Indeed 'mplayer' had 3 security updates so far in Etch. No one of those security updates was fixed by patching code in the ffmpeg library. So this whole bug 395252 is based on an apriori assumption; moreover this assumption was proved wrong by facts. Summarizing, you are deciding that mplayer is too buggy to be supported because of a bug that claims that same argument. Don't you see how circular this whole reasoning is? Not to mention that, for reasons behond my comprehension, mplayer is the only package targetted by this reasoning. 1) As I said in the other email, the policy 3.8.0 now contains a paragraph [14.3] against embedded copies, that is though waived for Lenny. For some reasons, you do not accept that mplayer be given the same treatment. 2) Another point is that http://svn.debian.org/wsvn/secure-testing/data/embedded-code-copies?op=filerev=0sc=0 lists many packages which ship embedded copies. One example is mozilla/iceweasel/iceape. Iceweasel had 9 security bugs in Etch. Iceweasel has ~500 bugs (!!). So iceweasel should be kept out of Lenny, since it contains embedded copies of code and is quite buggy. But no one is ever posting this RC bug. Why? Beats me. Note iceweasel 3.0, which is planned for Lenny, while it contains embedded copy of code, does *not* use it. Find another example. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#395252: ignore bug 395252 'mplayer embeds ffmpeg' for lenny
On Wed, Jun 18, 2008 at 02:09:06PM +0200, A Mennucc wrote: lists many packages which ship embedded copies. One example is mozilla/iceweasel/iceape. Iceweasel had 9 security bugs in Etch. Iceweasel has ~500 bugs (!!). So iceweasel should be kept out of Lenny, since it contains embedded copies of code and is quite buggy. But no one is ever posting this RC bug. Why? Beats me. In fact, recently iceweasel was made to build to on top of xulrunner instead of embedding it, and work is done to make more applications mozilla apps to do the same. The originating issue here is that embedded copies requires extra work for security team. Thus one strategy to convince people to grant mplayer a execption is that you can take this workload from them, and will not go MIA during the next release cycle. I don't know if such arrangments are being considered by the security/release teams. Or maybe try If I fix n RC bugs, would you grant a exception for mplayer? ;). Be positive and creative rather than negative and bureacratic. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#395252: ignore bug 395252 'mplayer embeds ffmpeg' for lenny
On Mon, Jun 16, 2008 at 04:21:50PM +0200, A Mennucc wrote: hi everybody Hello, and thanks for your mail. I am requesting to the d-release team a lenny-ignore tag for bug 395252. I'm afraid I can't accede to your request. This bug has been open since 25 Oct 2006. The etch-ignore tag was added 16 Dec 2006, where it was explicitly stated that it's RC for lenny. I pinged the bug on 28 Mar 2008, to again state that it's RC for lenny. I'm concerned as to why there as been seemingly no progress in over a year to resolving this issue. Neil -- Roses are Red Violets are Blue In Soviet Russia Poem writes YOU!! signature.asc Description: Digital signature
Bug#395252: ignore bug 395252 'mplayer embeds ffmpeg' for lenny
hi everybody I am requesting to the d-release team a lenny-ignore tag for bug 395252. There are multiple reasons for this request, please take some time to read ahead. --- Reason 1 : policy Recently, after a long discussion in bug 392362, a paragraph [4.13] was added to d-policy 3.8.0 stating (briefly) that: Some software packages include in their distribution convenience copies of code from other software packages [...] Debian packages should not make use of these convenience copies unless the included package is explicitly intended to be used in this way. This change was advertised in the email of early June by Russ Allbery to d-devel-announce, http://lists.debian.org/debian-devel-announce/2008/06/msg1.html The message starts by saying: Please note that the Policy release cycle is not currently well-synchronized with the release cycle, and adjusting to this version of Policy is *not* a priority for the upcoming lenny release unless the relevant provision has already separately been accepted as a release goal. I do not find [4.13] in http://release.debian.org/lenny/goals.txt , so I assume that unless part does not apply. So, the matter of bug 395252 (that was vehemently discussed there) is now settled once and for all in the debian policy. But there is an exception for lenny, and for this reason I am asking for a tag for this bug. [This also addresses a complaint of me and of Joey Hess, that is, why was mplayer singled out on this issue? Now no package is singled out, the bug is not RC for lenny, it will be RC for all packages after Lenny. I find this fair.] Reason 2: it does not work The other reason is that I did not find a way to comply to the request. There are two problems. ---2.1 missing headers and code in -dev files When 'mplayer' is compiled, it uses a lot of *.h files from its embedded ffmpeg; moreover, its 'configure' file scans some *.c files to get the up-to-date listing of supported codecs etc etc. Unfortunately, the -dev binary packages generated by ffmpeg-free contain only a small part of all the needed stuff. This said, I manually copied all needed stuff so as to compile all code, but... 2.2 the mplayer binary does not link with the ffmpeg-free libs. By reading and diffing, it would seem that the newer ffmpeg-free 0.svn20080206 source code seems compatible to the ffmpeg code shipped in mplayer... but unfortunately when I try to link, it fails. The error is in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=395252#226 I think that the problem is that the 'ffmpeg-free' code in Debian does not contain all the upstream code; and then, to be able to compile, there are many quilt patches that affect the shipped code, and a restrictive 'configure' call. All this kills some symbols that 'mplayer' needs. Unfortunately I could not properly identify where and why this linking failure originates. This is why I add a 'help' tag to the bug. If there is some simple way out of this that I am overseeing, please tell. -- reason 3: ffmpeg is in transition One insight that I got from all the above is that , to link mplayer to ffmpeg-free generated libraries, there are possibly many changes to be made in ffmpeg-free. But this is not a good time to change those libraries, that are in a transition. a. -- Andrea Mennucc The EULA sounds like it was written by a team of lawyers who want to tell me what I can't do, and the GPL sounds like it was written by a human being who wants me to know what I can do. Anonymous,http://www.securityfocus.com/columnists/420 signature.asc Description: Digital signature
Bug#395252: ignore bug 395252 'mplayer embeds ffmpeg' for lenny
On Mon, Jun 16, 2008 at 04:21:50PM +0200, A Mennucc wrote: 2.2 the mplayer binary does not link with the ffmpeg-free libs. By reading and diffing, it would seem that the newer ffmpeg-free 0.svn20080206 source code seems compatible to the ffmpeg code shipped in mplayer... but unfortunately when I try to link, it fails. The error is in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=395252#226 To me it looks like either you are missing a -lavutil or have it at the wrong place. Note that compiling with and out-of-tree libavutil is and will not be supported by upstream at least for now since MPlayer depends on some of its internal functions that can not be exported cleanly (features that depend on a FFmpeg-compatible config.h). Greetings, Reimar Döffinger -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
