Bug#729203: Packaging for FFmpeg avoiding conflicts with libav
On Wed, Feb 26, 2014 at 04:49:09PM +0100, Moritz Mühlenhoff wrote: > On Wed, Feb 26, 2014 at 02:30:47AM +0100, Michael Niedermayer wrote: > > > Yes, it's the latter: I didn't badmouth ffmpeg in any way: it was said > > > that libav > > > fixed less Google fuzzer samples than libav; for which I added my > > > observation that when > > > I looked at several CVE assignments for ffmpeg fixes the affected code > > > didn't exist in libav releases and that explains the difference in > > > numbers. > > > That doesn't mean that ffmpeg is worse than libav, it simply means that > > > the > > > code has diverged and different code is affected. > > > > I belive maybe some things are a bit mixed up here > > The "less fixes in libav" stuff was AFAIK a comparission between the > > libav and ffmpeg git master branches > > I'm referring to issues listed on ffmpeg.org/security for which I checked > the applicability to libav as in Debian. One thing I remember was the > g2meet codec which wasn't in any libav branch in Debian. > > Anyway, I don't have time to discuss this in depth. g2meet was added to libav Mon Jun 3 09:24:55 2013 +0200 commit 2d66a58ccde05e764594bd7e5f0f9244634d0b2c and to ffmpeg on Mon Jun 3 12:47:26 2013 +0200 commit e5cdf9c03b1ef0913dad117b0e5d343a525f6d10 the added code was identical, except the project name in the header On the FFmpeg side the 3 security issues from the security page where fixed in the code in e07ac72 Michael Niedermayer 2013-09-21 2013-09-22 avcodec/g2meet: Fix framebuf size 821a593 Michael Niedermayer 2013-09-15 2013-09-15 avcodec/g2meet: Fix order of align and pixel size multiplication. 2960576 Michael Niedermayer 2013-08-07 2013-08-07 avcodec/g2meet: fix src pointer checks in kempf_decode_tile() These where also all backported to the only FFmpeg release that contained g2meet at that time None of these 3 commits is in libav master AFAIK or their latest alpha or beta. Are they affected by these bugs, i dont know, i did not investigate. And as you picked this example If you would compare FFmpeg vs. Libav with it For FFmpeg none of the latest releases from any release branch are affected by it you can saftely ship/use any with no work testing or backporting any security issues. also had debian taken FFmpeg instead of Libav for Wheezy or any prior debian release, it also would not have affected debian any bit more as no FFmpeg release at that time contained the affected code. Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you think the mosad wants you dead since a long time then you are either wrong or dead since a long time. signature.asc Description: Digital signature
Bug#729203: Packaging for FFmpeg avoiding conflicts with libav
On Wed, Feb 26, 2014 at 01:39:23AM +, Clint Adams wrote: > Ideally someone should upload ffmpeg to unstable instead of > endlessly discussing it. I don't see anyone preventing this > yet. Seconded. I felt that Moritz's last message (when it was the last message) was fine - let's get it into unstable, and /prove/ that security issues can be managed, by managing them. That will go a long way towards building trust in the ffmpeg-packaging-team (whoever that might be. Still to be resolved I guess) can handle it. It will also address the issue for a large chunk of Debian users, who use sid anyway. And before someone actually uploads the thing - can we please get it into a git repo; clarify the team arrangements (collab-maint or set up a new one?); and can we reach an agreement on whether the first upload offers a binary ffmpeg package only (my preference), before we attempt to tackle the library co-installation (which might take a lot longer, require ftp master convincing etc.) -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140226201706.ga9...@bryant.redmars.org
Bug#729203: Packaging for FFmpeg avoiding conflicts with libav
Hi Antoine, On 26.02.2014 14:15, Antoine Beaupré wrote: On 2014-02-26 04:56:02, Andreas Cadhalpun wrote: At the moment I think Antoine is still reviewing my packaging before sponsoring an upload. This was a misunderstanding - I thought more work would be done on the package first. :) I think it would be good, if you could upload it to experimental now, because I would like to know, if FFmpeg builds on all architectures. You could use the new upstream version 2.1.4 for this, simply by downloading the tarball [1] and changing the version in debian/changelog (trivial patch attached). Is there a git repo or is there only the stuff you sent as an attachment? I have a local git repo created via git-import-dsc. It would probably be good to make this available somewhere. But the debian.tar.xz and the upstream tarball should be enough to build the package with debuild. If you need anything else, just ask. By the way, Alexander Strasser from FFmpeg upstream has volunteered to co-maintain FFmpeg in Debian. Best regards, Andreas 1: https://ffmpeg.org/releases/ffmpeg-2.1.4.tar.gz diff --cc debian/changelog index e6697cc,000..4864cdd @@@ -1,9 -1,0 +1,9 @@@ - ffmpeg (4:2.1.3-1) experimental; urgency=medium ++ffmpeg (4:2.1.4-1) experimental; urgency=medium + + * Reintroduce FFmpeg to Debian. (Closes: #729203) +There are far to many changes since FFmpeg 0.5 to mention them here, see: - https://git.videolan.org/?p=ffmpeg.git;a=shortlog;h=n2.1.3 ++https://git.videolan.org/?p=ffmpeg.git;a=shortlog;h=n2.1.4 +Many security issues have been fixed as well, see: +https://ffmpeg.org/security.html + - -- Andreas Cadhalpun Tue, 25 Feb 2014 11:03:38 +0100 ++ -- Andreas Cadhalpun Wed, 26 Feb 2014 15:30:25 +0100
Bug#729203: Packaging for FFmpeg avoiding conflicts with libav
On Tue, Feb 25, 2014 at 11:30:25PM +0100, Andreas Cadhalpun wrote: > But then the security team represented by Moritz stated that they > would not support both FFmpeg and libav, so they are the only ones > affected negatively by FFmpeg in stable. Thus I think it doesn't > make much sense to discuss with anyone but the security team. > > Ideally the security team should now evaluate which of the two are > better from a security point of view and based on this decide, which > one they would prefer to see in jessie. > But if they don't, someone else will have to make this decision. Personally I've fine with either libav or ffmpeg. This decision should be made by the Debian multimedia maintainers, since they're affected the most. Anyway, as said before I EOD for me, please stop CCing me on everthing. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140226155439.GG4558@pisco.westfalen.local
Bug#729203: Packaging for FFmpeg avoiding conflicts with libav
On Wed, Feb 26, 2014 at 02:30:47AM +0100, Michael Niedermayer wrote: > > Yes, it's the latter: I didn't badmouth ffmpeg in any way: it was said that > > libav > > fixed less Google fuzzer samples than libav; for which I added my > > observation that when > > I looked at several CVE assignments for ffmpeg fixes the affected code > > didn't exist in libav releases and that explains the difference in numbers. > > That doesn't mean that ffmpeg is worse than libav, it simply means that the > > code has diverged and different code is affected. > > I belive maybe some things are a bit mixed up here > The "less fixes in libav" stuff was AFAIK a comparission between the > libav and ffmpeg git master branches I'm referring to issues listed on ffmpeg.org/security for which I checked the applicability to libav as in Debian. One thing I remember was the g2meet codec which wasn't in any libav branch in Debian. Anyway, I don't have time to discuss this in depth. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140226154909.GF4558@pisco.westfalen.local
Bug#729203: Packaging for FFmpeg avoiding conflicts with libav
On 2014-02-26 04:56:02, Andreas Cadhalpun wrote: > Hi Clint, > > On 26.02.2014 02:39, Clint Adams wrote: >> On Tue, Feb 25, 2014 at 11:30:25PM +0100, Andreas Cadhalpun wrote: >>> Ideally the security team should now evaluate which of the two are >>> better from a security point of view and based on this decide, which >>> one they would prefer to see in jessie. >>> But if they don't, someone else will have to make this decision. >> >> Ideally someone should upload ffmpeg to unstable instead of >> endlessly discussing it. I don't see anyone preventing this >> yet. > > Sorry, if I didn't make myself clear: Of course this discussion doesn't > prevent an upload to unstable, but at some point this has to be > discussed and I see no harm in starting such a discussion as early as > possible. > > At the moment I think Antoine is still reviewing my packaging before > sponsoring an upload. This was a misunderstanding - I thought more work would be done on the package first. :) Is there a git repo or is there only the stuff you sent as an attachment? > If you want to speed things up, you are very welcome to become a > co-maintainer and upload as soon as you like. Of course if Clints wants to sponsor the package, that would be great! :) A. -- VBscript: la simplicité du C, la puissance du BASIC - Mathieu Petit-Clair pgp1Ekx2yFPVB.pgp Description: PGP signature
Bug#729203: Packaging for FFmpeg avoiding conflicts with libav
Hi Michael, On 26.02.2014 02:44, Michael Gilbert wrote: On Tue, Feb 25, 2014 at 8:39 PM, Michael Niedermayer wrote: Id like to volunteer to help with any future security issues in FFmpeg packages in debian. The best place to start is testing and (more preferably) patches for the present libav issues. There are 18 of them: https://security-tracker.debian.org/tracker/source-package/libav Thanks for trying to make a constructive comment, but I'm not sure what you want Michael Niedermayer to do. Quoting myself [0]: "[...] I would be very interested in an explanation of the current state of the security tracker for libav [1], as *all* issues currently marked as open for libav are CVEs issued by FFmpeg about problems they fixed [2]. One, CVE-2011-3935, is even several years old *and* fixed for the FFmpeg in old-stable! I don't know whether to laugh or cry." Maybe you thought it was a joke? It was not, just compare the CVE numbers on [1] and [2]. I don't know if these actually affect libav, but I guess they wouldn't be on the security tracker, if they didn't. These CVEs are usually linked to the git commits that fix the problems, so there are already tested (in the sense that FFmpeg uses them) patches. If you want Micheal Niedermayer to send these patches to libav upstream, I think you would have to convince them to remove some bans from their mailing lists. Good luck with that. Best regards, Andreas 0: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729203#475 1: https://security-tracker.debian.org/tracker/source-package/libav 2: https://ffmpeg.org/security.html -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/530dd576.6060...@googlemail.com
Bug#729203: Packaging for FFmpeg avoiding conflicts with libav
Hi Clint, On 26.02.2014 02:39, Clint Adams wrote: On Tue, Feb 25, 2014 at 11:30:25PM +0100, Andreas Cadhalpun wrote: Ideally the security team should now evaluate which of the two are better from a security point of view and based on this decide, which one they would prefer to see in jessie. But if they don't, someone else will have to make this decision. Ideally someone should upload ffmpeg to unstable instead of endlessly discussing it. I don't see anyone preventing this yet. Sorry, if I didn't make myself clear: Of course this discussion doesn't prevent an upload to unstable, but at some point this has to be discussed and I see no harm in starting such a discussion as early as possible. At the moment I think Antoine is still reviewing my packaging before sponsoring an upload. If you want to speed things up, you are very welcome to become a co-maintainer and upload as soon as you like. Best regards, Andreas -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/530dba32.30...@googlemail.com
Bug#729203: Packaging for FFmpeg avoiding conflicts with libav
On Tue, Feb 25, 2014 at 8:39 PM, Michael Niedermayer wrote: >> The security team made it abundantly clear that we will only support >> either solution. If you go ahead with the ITP we'll file an RC bug >> against ffmpeg to prevent it's transition to testing. You can then >> sort out how/whether ffmpeg should _replace_ libav, but both are not >> an option. > > Id like to volunteer to help with any future security issues in > FFmpeg packages in debian. The best place to start is testing and (more preferably) patches for the present libav issues. There are 18 of them: https://security-tracker.debian.org/tracker/source-package/libav Best wishes, Mike -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANTw=mosbtvr71s5w4ljdzsycy9cj81wa+fptme-k9skkox...@mail.gmail.com
Bug#729203: Packaging for FFmpeg avoiding conflicts with libav
On Tue, Feb 25, 2014 at 11:30:25PM +0100, Andreas Cadhalpun wrote: > Ideally the security team should now evaluate which of the two are > better from a security point of view and based on this decide, which > one they would prefer to see in jessie. > But if they don't, someone else will have to make this decision. Ideally someone should upload ffmpeg to unstable instead of endlessly discussing it. I don't see anyone preventing this yet. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140226013923.ga25...@scru.org
Bug#729203: Packaging for FFmpeg avoiding conflicts with libav
On Tue, Feb 25, 2014 at 05:57:02PM +0100, Moritz Mühlenhoff wrote: > On Sun, Feb 23, 2014 at 11:36:36PM +0100, Andreas Cadhalpun wrote: > > Hi Moritz, > > > > On 23.02.2014 22:56, Moritz Mühlenhoff wrote: > > >I don't have the time nor the interest to discuss this at length, so > > >EOD from my side. > > > > since you started this discussion by effectively preventing FFmpeg > > from being uploaded, I take it that you ending this discussion now > > means FFmpeg can be uploaded and you prefer to "be working with the > > release team to sort this out for jessie", after FFmpeg has reached > > testing. > > No, it means I don't have the time, nor nerve to discuss this. We're > after all busy to keep Debian secure and sick of maintainers who only > focus on their pet package and neglegt the overall maintainability > of the Debian archive. > > The security team made it abundantly clear that we will only support > either solution. If you go ahead with the ITP we'll file an RC bug > against ffmpeg to prevent it's transition to testing. You can then > sort out how/whether ffmpeg should _replace_ libav, but both are not > an option. Id like to volunteer to help with any future security issues in FFmpeg packages in debian. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB DNS cache poisoning attacks, popular search engine, Google internet authority dont be evil, please signature.asc Description: Digital signature
Bug#729203: Packaging for FFmpeg avoiding conflicts with libav
On Tue, Feb 25, 2014 at 11:33:33PM +0100, Moritz Muehlenhoff wrote: > On Tue, Feb 25, 2014 at 11:30:25PM +0100, Andreas Cadhalpun wrote: > > On 25.02.2014 22:18, Yves-Alexis Perez wrote: > >> On Tue, Feb 25, 2014 at 06:23:20PM +0100, Andreas Cadhalpun wrote: > No, it means I don't have the time, nor nerve to discuss this. We're > after all busy to keep Debian secure and sick of maintainers who only > focus on their pet package and neglegt the overall maintainability > of the Debian archive. > >>> > >>> While I always stated that I'm open to discussion, you just ended > >>> the discussion after trying to block FFmpeg from entering Debian, > >>> which I do not find very constructive. > >> > >> My feeling is that this was discussed over and over and Moritz is > >> /slighly/ tired of repeating the same thing over and over. And me > >> replying to this mail doesn't mean I'm willing to engage in a large > >> thread on this, the security team position has been given. > > > > My impression has been /slightly/ different: Moritz made dubious claims > > about FFmpeg: > > "We've looked into many security issues > > in ffmpeg which didn't affect libav, either because experimental > > code wasn't merged yet or because code was rewritten in libav and not > > affected. Also ffmpeg hasn't have long term branches which is a major > > benefit of libav." > > > > After I have questioned these, Moritz simply left the discussion. But > > maybe I didn't understand what Moritz wanted to say? > > Yes, it's the latter: I didn't badmouth ffmpeg in any way: it was said that > libav > fixed less Google fuzzer samples than libav; for which I added my observation > that when > I looked at several CVE assignments for ffmpeg fixes the affected code > didn't exist in libav releases and that explains the difference in numbers. > That doesn't mean that ffmpeg is worse than libav, it simply means that the > code has diverged and different code is affected. I belive maybe some things are a bit mixed up here The "less fixes in libav" stuff was AFAIK a comparission between the libav and ffmpeg git master branches while libavs last release was based on git master of over a year ago. So please correct me if iam wrong, but i dont think that a comparission of libav from over a year ago against recent issues can serve as an explanation for differences in the 2 projects master branches [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Awnsering whenever a program halts or runs forever is On a turing machine, in general impossible (turings halting problem). On any real computer, always possible as a real computer has a finite number of states N, and will either halt in less than N cycles or never halt. signature.asc Description: Digital signature
Bug#729203: Packaging for FFmpeg avoiding conflicts with libav
On Tue, Feb 25, 2014 at 11:30:25PM +0100, Andreas Cadhalpun wrote: > On 25.02.2014 22:18, Yves-Alexis Perez wrote: >> On Tue, Feb 25, 2014 at 06:23:20PM +0100, Andreas Cadhalpun wrote: No, it means I don't have the time, nor nerve to discuss this. We're after all busy to keep Debian secure and sick of maintainers who only focus on their pet package and neglegt the overall maintainability of the Debian archive. >>> >>> While I always stated that I'm open to discussion, you just ended >>> the discussion after trying to block FFmpeg from entering Debian, >>> which I do not find very constructive. >> >> My feeling is that this was discussed over and over and Moritz is >> /slighly/ tired of repeating the same thing over and over. And me >> replying to this mail doesn't mean I'm willing to engage in a large >> thread on this, the security team position has been given. > > My impression has been /slightly/ different: Moritz made dubious claims > about FFmpeg: > "We've looked into many security issues > in ffmpeg which didn't affect libav, either because experimental > code wasn't merged yet or because code was rewritten in libav and not > affected. Also ffmpeg hasn't have long term branches which is a major > benefit of libav." > > After I have questioned these, Moritz simply left the discussion. But > maybe I didn't understand what Moritz wanted to say? Yes, it's the latter: I didn't badmouth ffmpeg in any way: it was said that libav fixed less Google fuzzer samples than libav; for which I added my observation that when I looked at several CVE assignments for ffmpeg fixes the affected code didn't exist in libav releases and that explains the difference in numbers. That doesn't mean that ffmpeg is worse than libav, it simply means that the code has diverged and different code is affected. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2014022522.ga19...@inutil.org
Bug#729203: Packaging for FFmpeg avoiding conflicts with libav
On 25.02.2014 22:18, Yves-Alexis Perez wrote: On Tue, Feb 25, 2014 at 06:23:20PM +0100, Andreas Cadhalpun wrote: No, it means I don't have the time, nor nerve to discuss this. We're after all busy to keep Debian secure and sick of maintainers who only focus on their pet package and neglegt the overall maintainability of the Debian archive. While I always stated that I'm open to discussion, you just ended the discussion after trying to block FFmpeg from entering Debian, which I do not find very constructive. My feeling is that this was discussed over and over and Moritz is /slighly/ tired of repeating the same thing over and over. And me replying to this mail doesn't mean I'm willing to engage in a large thread on this, the security team position has been given. My impression has been /slightly/ different: Moritz made dubious claims about FFmpeg: "We've looked into many security issues in ffmpeg which didn't affect libav, either because experimental code wasn't merged yet or because code was rewritten in libav and not affected. Also ffmpeg hasn't have long term branches which is a major benefit of libav." After I have questioned these, Moritz simply left the discussion. But maybe I didn't understand what Moritz wanted to say? I want to see FFmpeg in Debian and I'm interested in any constructive discussion about problems that might bring for others. If you don't have time for such a discussion that is a pity. Well, as it was already sated, the discussion needs to happen with libav maintainers (and reverse dependencies indeed). What do you think a discussion with them will gain? Maybe it's not clear to everyone: Upstream FFmpeg and upstream libav are not exactly friendly towards each other. Furthermore some important developers of libav are among the Debian maintainers of libav. Therefore I fear that any discussion with the libav maintainers about FFmpeg would likely end in a flamewar, which I tried to avoid. Therefore I packaged FFmpeg in a way that doesn't conflict with libav, so that FFmpeg in Debian is neither a concern for the libav developers nor for anyone who wants to use libav, but that allows those, who need FFmpeg due to the additional features it provides, to use it. But then the security team represented by Moritz stated that they would not support both FFmpeg and libav, so they are the only ones affected negatively by FFmpeg in stable. Thus I think it doesn't make much sense to discuss with anyone but the security team. Ideally the security team should now evaluate which of the two are better from a security point of view and based on this decide, which one they would prefer to see in jessie. But if they don't, someone else will have to make this decision. Best regards, Andreas -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/530d1981.1050...@googlemail.com
Bug#729203: Packaging for FFmpeg avoiding conflicts with libav
On Tue, Feb 25, 2014 at 06:23:20PM +0100, Andreas Cadhalpun wrote: > >No, it means I don't have the time, nor nerve to discuss this. We're > >after all busy to keep Debian secure and sick of maintainers who only > >focus on their pet package and neglegt the overall maintainability > >of the Debian archive. > > While I always stated that I'm open to discussion, you just ended > the discussion after trying to block FFmpeg from entering Debian, > which I do not find very constructive. My feeling is that this was discussed over and over and Moritz is /slighly/ tired of repeating the same thing over and over. And me replying to this mail doesn't mean I'm willing to engage in a large thread on this, the security team position has been given. > > I want to see FFmpeg in Debian and I'm interested in any > constructive discussion about problems that might bring for others. > If you don't have time for such a discussion that is a pity. Well, as it was already sated, the discussion needs to happen with libav maintainers (and reverse dependencies indeed). -- Yves-Alexis Perez Debian security team signature.asc Description: Digital signature
Bug#729203: Packaging for FFmpeg avoiding conflicts with libav
Hi Moritz, On 25.02.2014 17:57, Moritz Mühlenhoff wrote: On Sun, Feb 23, 2014 at 11:36:36PM +0100, Andreas Cadhalpun wrote: Hi Moritz, On 23.02.2014 22:56, Moritz Mühlenhoff wrote: I don't have the time nor the interest to discuss this at length, so EOD from my side. since you started this discussion by effectively preventing FFmpeg from being uploaded, I take it that you ending this discussion now means FFmpeg can be uploaded and you prefer to "be working with the release team to sort this out for jessie", after FFmpeg has reached testing. No, it means I don't have the time, nor nerve to discuss this. We're after all busy to keep Debian secure and sick of maintainers who only focus on their pet package and neglegt the overall maintainability of the Debian archive. While I always stated that I'm open to discussion, you just ended the discussion after trying to block FFmpeg from entering Debian, which I do not find very constructive. Whether you believe it or not, my pet project is called Debian and I want to see the best possible software in it. You may have noticed that a lot of people are unhappy with the current situation of only having libav. I tried to package FFmpeg in a way that has the smallest possible impact on the current Debian archive, i.e. as coinstallable with libav. The security team made it abundantly clear that we will only support either solution. If you go ahead with the ITP we'll file an RC bug against ffmpeg to prevent it's transition to testing. You can then sort out how/whether ffmpeg should _replace_ libav, but both are not an option. You can do however you like, but so can everyone else. I want to see FFmpeg in Debian and I'm interested in any constructive discussion about problems that might bring for others. If you don't have time for such a discussion that is a pity. Best regards, Andreas -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/530cd188.30...@googlemail.com
Bug#729203: Packaging for FFmpeg avoiding conflicts with libav
On Sun, Feb 23, 2014 at 11:36:36PM +0100, Andreas Cadhalpun wrote: > Hi Moritz, > > On 23.02.2014 22:56, Moritz Mühlenhoff wrote: > >I don't have the time nor the interest to discuss this at length, so > >EOD from my side. > > since you started this discussion by effectively preventing FFmpeg > from being uploaded, I take it that you ending this discussion now > means FFmpeg can be uploaded and you prefer to "be working with the > release team to sort this out for jessie", after FFmpeg has reached > testing. No, it means I don't have the time, nor nerve to discuss this. We're after all busy to keep Debian secure and sick of maintainers who only focus on their pet package and neglegt the overall maintainability of the Debian archive. The security team made it abundantly clear that we will only support either solution. If you go ahead with the ITP we'll file an RC bug against ffmpeg to prevent it's transition to testing. You can then sort out how/whether ffmpeg should _replace_ libav, but both are not an option. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140225165702.GA2960@pisco.westfalen.local
Bug#729203: Packaging for FFmpeg avoiding conflicts with libav
Hi Moritz, On 23.02.2014 22:56, Moritz Mühlenhoff wrote: I don't have the time nor the interest to discuss this at length, so EOD from my side. since you started this discussion by effectively preventing FFmpeg from being uploaded, I take it that you ending this discussion now means FFmpeg can be uploaded and you prefer to "be working with the release team to sort this out for jessie", after FFmpeg has reached testing. Or what is supposed to happen? Best regards, Andreas -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/530a77f4.2050...@googlemail.com
Bug#729203: Packaging for FFmpeg avoiding conflicts with libav
On Sun, Feb 23, 2014 at 12:48:34PM +0200, Adrian Bunk wrote: > On Sun, Feb 23, 2014 at 10:53:18AM +0100, Moritz Mühlenhoff wrote: > > On Sat, Feb 22, 2014 at 08:18:20PM +0100, Andreas Cadhalpun wrote: > >... > > > But should they decide that it will not be possible to support both > > > packages for security updates, your argumentation would clearly > > > favor ffmpeg over libav, probably leading to the removal of libav > > > from the archive. > > > > I don't think that's the case. We've looked into many security issues > > in ffmpeg which didn't affect libav, either because experimental > > code wasn't merged yet or because code was rewritten in libav and not > > affected. > > A significant factor is that libav provides a subset of FFmpeg, > and breaks existing APIs frequently. I don't have the time nor the interest to discuss this at length, so EOD from my side. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140223215636.GA3103@pisco.westfalen.local
Bug#729203: Packaging for FFmpeg avoiding conflicts with libav
On Sun, Feb 23, 2014 at 12:38:17PM +0100, Andreas Cadhalpun wrote: >... > On 23.02.2014 11:48, Adrian Bunk wrote: >... > > E.g. except for the idea of removing this pretty popular package > > in favour of a dead fork, I don't recall any solution proposed > > for getting MPlayer compile again in unstable. > > As a side note, neither MPlayer nor MPlayer2 compile with this > FFmpeg package due to the removal of CodecID. The same holds for > libav10. >... This was fixed in MPlayer upstream a year ago. > Best regards, > Andreas >... cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140223173505.gg11...@bunk.dyndns.info
Bug#729203: Packaging for FFmpeg avoiding conflicts with libav
[Adding the CCs again, I hope you don't mind.]
Hi Timothy,
thanks for your remarks and sorry for not responding sooner, I got
distracted...
On 22.02.2014 20:39, Timothy Gu wrote:
On Sat, Feb 22, 2014 at 11:18 AM, Andreas Cadhalpun
wrote:
Upstream thinks qt-faststart is not used very often nowadays and
there are not many differences between the ffmpeg and the libav
version. So anyone who needs qt-faststart can install libav-tools. I
don't see a need for a qt-faststart binary package, but if there
were bugs in the libav version that are not in the ffmpeg version,
we could create a qt-faststart package.
IIRC FFmpeg qt-faststart is faster than Libav because of
http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=f4d9148fe282879b9fcc755767c9c04de9ddbcfa.
That's exactly the kind of bug that I think justifies a qt-faststart
package. So I added it, see attached patch. It diverts the qt-faststart
from libav to qt-faststart.libav.
I fixed most of the lintian problems, but some remain:
* E: debian-watch-file-pubkey-file-is-missing:
This is a bug in lintian [2].
* E: embedded-library: I don't understand this one:
Does it complain about libavfilter embedding libavfilter?
Seems like a bug in lintian.
Not sure about those.
Well, the first is a bug in lintian due to the transition from
debian/upstream-signing-key.pgp to
debian/upstream/signing-key.{asc,pgp},
discussed on debian-devel recently.
The second is a mystery to me.
Does the libav package has those warnings?
Libav doesn't have this errors, because it still uses the old location
of the signing-key and according to Raphael lintian detects the embedded
libraries by checking a known list of "sources", which contains libav,
but obviously not the newly created ffmpeg package.
But libav has the warnings about the manpage as well. [1]
* W: manpage-has-errors-from-man:
I don't know how to fix the manpages. Can someone help?
I had the manpage errors as well, I think we can ignore those for now.
I figured this as well, but maybe someone knows how to fix it.
That is upstream problem. See e.g. ffmpeg/doc/ffmpeg.texi ll. 805 [1].
So it seems the line is just to long, but it probably doesn't make sense
to break it. So is this a wontfix? If so we should add a lintian
override explaining the problem.
With this package, users can install either ffmpeg or libav-tools
and developers can either depend on lib*-ffmpeg-dev or on lib*-dev
and everyone should be happy.
That would be awesome.
Exactly my opinion. ;)
By the way, of course users can also install both ffmpeg and
libav-tools and also packages build against ffmpeg and other
packages build against libav.
Yay! I didn't think of a way good enough like that.
Thank you so much for all your work!
Unfortunately it seems that the security team will not allow both FFmpeg
and libav in a stable release.
Best regards,
Andreas
1:
http://lintian.debian.org/maintainer/pkg-multimedia-maintain...@lists.alioth.debian.org.html#libav
diff -ruN debian.orig/control debian/control
--- debian.orig/control 2014-02-22 12:55:59.0 +0100
+++ debian/control 2014-02-22 23:02:23.0 +0100
@@ -115,6 +115,25 @@
* ffprobe: a simple multimedia stream analyzer
.
NOTE: It does not contain qt-faststart to avoid a conflict with libav-tools.
+ If you need qt-faststart from ffmepg, install the package qt-faststart.
+
+Package: qt-faststart
+Architecture: any
+Multi-Arch: foreign
+Depends:
+ ${shlibs:Depends},
+ ${misc:Depends}
+Description: Utility to rearrange a Quicktime file
+ FFmpeg is the leading multimedia framework, able to decode, encode, transcode,
+ mux, demux, stream, filter and play pretty much anything that humans and
+ machines have created. It supports the most obscure ancient formats up to the
+ cutting edge.
+ .
+ This package contains qt-faststart, a utility that rearranges a Quicktime
+ file such that the moov atom is in front of the data, thus facilitating
+ network streaming.
+ .
+ NOTE: It diverts the qt-faststart from libav-tools to qt-faststart.libav.
Package: ffmpeg-dbg
Section: debug
diff -ruN debian.orig/copyright debian/copyright
--- debian.orig/copyright 2014-02-21 18:17:07.0 +0100
+++ debian/copyright 2014-02-22 21:17:38.0 +0100
@@ -835,3 +835,8 @@
License along with this packaging; if not, write to the Free Software
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+Files: debian/qt-faststart.1
+Copyright: Andres Mejia
+License: public-domain
+ This manual page was written by Andres Mejia
+ for the Debian GNU/Linux system, but may be used by others.
diff -ruN debian.orig/qt-faststart.1 debian/qt-faststart.1
--- debian.orig/qt-faststart.1 1970-01-01 01:00:00.0 +0100
+++ debian/qt-faststart.1 2014-01-18 16:50:35.0 +0100
@@ -0,0 +1,36 @@
+.\" Hey, EMACS: -*- nroff -*-
+.\" First parameter, NAME,
Bug#729203: Packaging for FFmpeg avoiding conflicts with libav
On Sun, Feb 23, 2014 at 10:53:18AM +0100, Moritz Mühlenhoff wrote: > On Sat, Feb 22, 2014 at 08:18:20PM +0100, Andreas Cadhalpun wrote: >... > > But should they decide that it will not be possible to support both > > packages for security updates, your argumentation would clearly > > favor ffmpeg over libav, probably leading to the removal of libav > > from the archive. > > I don't think that's the case. We've looked into many security issues > in ffmpeg which didn't affect libav, either because experimental > code wasn't merged yet or because code was rewritten in libav and not > affected. A significant factor is that libav provides a subset of FFmpeg, and breaks existing APIs frequently. E.g. except for the idea of removing this pretty popular package in favour of a dead fork, I don't recall any solution proposed for getting MPlayer compile again in unstable. More code tends to have more bugs, so it's not fair to compare the raw number of bugs for two projects where one provides a subset of the other. And is there any explanation for the claim that libav is much slower than FFmpeg in merging fixes for issues that seem to be clear bugs, many of them might have a security impact? [1] > Also ffmpeg hasn't have long term branches which is a major > benefit of libav. If there is demand, my impression is that FFmpeg upstream would be willing to discuss providing stable branches that are supported for 2 years like libav. A Debian release is supported by you for around 4 years after the release of the latest libav.[2] Is there any commitment from libav upstream to provide support for the second half of that time?[3] > Cheers, > Moritz cu Adrian [1] http://googleonlinesecurity.blogspot.fi/2014/01/ffmpeg-and-thousand-fixes.html [2] the libav branch is on average half a year old when Debian freezes, plus half a year freeze plus 2 years until the next Debian stable plus 1 year [3] this is not meant against libav, I am just asking about the status quo -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140223104834.ga11...@bunk.dyndns.info
Bug#729203: Packaging for FFmpeg avoiding conflicts with libav
On Sat, Feb 22, 2014 at 08:18:20PM +0100, Andreas Cadhalpun wrote: > >>Adrian, do you agree that this is sane? > >> > >>If the security team is not willing to support both, they can ask the TC > >>to decide which one to use, but this does not prevent an upload of FFmpeg. > > > >I don't see why security would complain: as things stand there are > >hundreds of security issues that have been fixed in ffmpeg (see the > >Google audit) which have not been fixed in libav... It seems to me > >ffmpeg is only more secure than libav at this point... > > Previously, Moritz Mühlenhoff from the security team voiced his > concerns about having to apply security fixes for both [1]: > "But we still try to minimise such cases as much as possible. And for > libav/ffmpeg this simply isn't managable at all due to the huge stream > of security issues trickling in. We need definitely need to pick one > solution only." > > I do not share these concerns, as there are e.g. mysql and mariadb > happily coexisting They are not "happily coexisting", we'll be working with the release team to sort this out for jessie. >, but then again, I'm not on the security team. Exactly. It makes it really easy to not share concerns if you're not affected by the work imposed from the decision. > But should they decide that it will not be possible to support both > packages for security updates, your argumentation would clearly > favor ffmpeg over libav, probably leading to the removal of libav > from the archive. I don't think that's the case. We've looked into many security issues in ffmpeg which didn't affect libav, either because experimental code wasn't merged yet or because code was rewritten in libav and not affected. Also ffmpeg hasn't have long term branches which is a major benefit of libav. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140223095318.GA3141@pisco.westfalen.local
Bug#729203: Packaging for FFmpeg avoiding conflicts with libav
Hi, [only replying with my lintian maintainer hat here, from the sec. point of view it would take a more lengthy mail] On Saturday 22 February 2014 18:39:20 Andreas Cadhalpun wrote: [...] > * E: embedded-library: I don't understand this one: >Does it complain about libavfilter embedding libavfilter? >Seems like a bug in lintian. It complains because it has detected a copy of libavfilter in a package which is none of the ones it knows that are the "source" of it. So arguably, yes, it's a bug. Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140045.01046.geiss...@debian.org
Bug#729203: Packaging for FFmpeg avoiding conflicts with libav
On Sat, Feb 22, 2014 at 11:18 AM, Andreas Cadhalpun
wrote:
> Hi Antoine,
>
>
> On 22.02.2014 18:56, Antoine Beaupr=E9 wrote:
>>
>> On 2014-02-22 12:39:20, Andreas Cadhalpun wrote:
>>> The ffmpeg package does not provide qt-faststart to avoid a conflict
>>> with libav-tools.
>>
>>
>> Fair enough - there could be a qt-faststart binary package which could
>> conflict with libav-tools.
>
>
> Upstream thinks qt-faststart is not used very often nowadays and there ar=
e
> not many differences between the ffmpeg and the libav version. So anyone =
who
> needs qt-faststart can install libav-tools. I don't see a need for a
> qt-faststart binary package, but if there were bugs in the libav version
> that are not in the ffmpeg version, we could create a qt-faststart packag=
e.
IIRC FFmpeg qt-faststart is faster than Libav because of
http://git.videolan.org/?p=3Dffmpeg.git;a=3Dcommitdiff;h=3Df4d9148fe282879b=
9fcc755767c9c04de9ddbcfa.
>
>
>>> I'm not sure if this package will build on every architecture, because =
I
>>> can't test that.
>>
>>
>> Maybe an upload to experimental could test that? :)
>
>
> I intended to suggest this first, but unfortunately something in
> experimental is broken, which leads to a test failure of ffmpeg, more
> specifically the test acodec-flac fails in experimental.
> It doesn't fail in unstable and testing, so an upload to unstable should =
be
> fine.
> But if it fails to build on some architecture, it will not enter testing,=
so
> there should be no problem in uploading to unstable.
>
>
>>> I fixed most of the lintian problems, but some remain:
>>>
>>>* E: debian-watch-file-pubkey-file-is-missing:
>>> This is a bug in lintian [2].
>>>* E: embedded-library: I don't understand this one:
>>> Does it complain about libavfilter embedding libavfilter?
>>> Seems like a bug in lintian.
>>
>>
>> Not sure about those.
>
>
> Well, the first is a bug in lintian due to the transition from
> debian/upstream-signing-key.pgp to debian/upstream/signing-key.{asc,pgp},
> discussed on debian-devel recently.
> The second is a mystery to me.
Does the libav package has those warnings?
>
>
>>>* W: manpage-has-errors-from-man:
>>> I don't know how to fix the manpages. Can someone help?
>>
>>
>> I had the manpage errors as well, I think we can ignore those for now.
>
>
> I figured this as well, but maybe someone knows how to fix it.
That is upstream problem. See e.g. ffmpeg/doc/ffmpeg.texi ll. 805 [1].
>
>
>>> With this package, users can install either ffmpeg or libav-tools and
>>> developers can either depend on lib*-ffmpeg-dev or on lib*-dev and
>>> everyone should be happy.
>>
>>
>> That would be awesome.
>
>
> Exactly my opinion. ;)
> By the way, of course users can also install both ffmpeg and libav-tools =
and
> also packages build against ffmpeg and other packages build against libav=
.
Yay! I didn't think of a way good enough like that.
>
>
>>> Adrian, do you agree that this is sane?
>>>
>>> If the security team is not willing to support both, they can ask the T=
C
>>> to decide which one to use, but this does not prevent an upload of
>>> FFmpeg.
>>
>>
>> I don't see why security would complain: as things stand there are
>> hundreds of security issues that have been fixed in ffmpeg (see the
>> Google audit) which have not been fixed in libav... It seems to me
>> ffmpeg is only more secure than libav at this point...
>
>
> Previously, Moritz M=FChlenhoff from the security team voiced his concern=
s
> about having to apply security fixes for both [1]:
> "But we still try to minimise such cases as much as possible. And for
> libav/ffmpeg this simply isn't managable at all due to the huge stream
> of security issues trickling in. We need definitely need to pick one
> solution only."
>
> I do not share these concerns, as there are e.g. mysql and mariadb happil=
y
> coexisting, but then again, I'm not on the security team.
>
> But should they decide that it will not be possible to support both packa=
ges
> for security updates, your argumentation would clearly favor ffmpeg over
> libav, probably leading to the removal of libav from the archive.
> From my point of view this would be wrong, as I think the users and
> developers should decide for themselves, which package they want to use, =
and
> preventing one from being distributed in Debian only produces a great amo=
unt
> of dissatisfaction and unhappiness among the users and developers.
Thank you so much for all your work!
[1] http://git.videolan.org/?p=3Dffmpeg.git;a=3Dblob;f=3Ddoc/ffmpeg.texi;h=
=3D1244cc4e031a26536f6f3587e50a00114adc8e85;hb=3DHEAD#l805
--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CA+Yu1_UP=GkCc26MOmgY-sNXp1GmC9gXec6E=x+jzmjnsbp...@mail.gmail.com
Bug#729203: Packaging for FFmpeg avoiding conflicts with libav
Hi Antoine,
On 22.02.2014 18:56, Antoine Beaupré wrote:
On 2014-02-22 12:39:20, Andreas Cadhalpun wrote:
>> Thus I have started from scratch and packaged FFmpeg 2.1.3 [1] (see
>> attached debian.tar.xz).
>
> Awesome!
;)
I have taken care to avoid conflicts with libav as far as possible, but
the development files have to conflict, as it is really no good idea to
build against both ffmpeg and libav at the same time.
You mean the -dev libraries?
Yes.
The ffmpeg package does not provide qt-faststart to avoid a conflict
with libav-tools.
Fair enough - there could be a qt-faststart binary package which could
conflict with libav-tools.
Upstream thinks qt-faststart is not used very often nowadays and there
are not many differences between the ffmpeg and the libav version. So
anyone who needs qt-faststart can install libav-tools. I don't see a
need for a qt-faststart binary package, but if there were bugs in the
libav version that are not in the ffmpeg version, we could create a
qt-faststart package.
I'm not sure if this package will build on every architecture, because I
can't test that.
Maybe an upload to experimental could test that? :)
I intended to suggest this first, but unfortunately something in
experimental is broken, which leads to a test failure of ffmpeg, more
specifically the test acodec-flac fails in experimental.
It doesn't fail in unstable and testing, so an upload to unstable should
be fine.
But if it fails to build on some architecture, it will not enter
testing, so there should be no problem in uploading to unstable.
I fixed most of the lintian problems, but some remain:
* E: debian-watch-file-pubkey-file-is-missing:
This is a bug in lintian [2].
* E: embedded-library: I don't understand this one:
Does it complain about libavfilter embedding libavfilter?
Seems like a bug in lintian.
Not sure about those.
Well, the first is a bug in lintian due to the transition from
debian/upstream-signing-key.pgp to
debian/upstream/signing-key.{asc,pgp}, discussed on debian-devel recently.
The second is a mystery to me.
* W: manpage-has-errors-from-man:
I don't know how to fix the manpages. Can someone help?
I had the manpage errors as well, I think we can ignore those for now.
I figured this as well, but maybe someone knows how to fix it.
With this package, users can install either ffmpeg or libav-tools and
developers can either depend on lib*-ffmpeg-dev or on lib*-dev and
everyone should be happy.
That would be awesome.
Exactly my opinion. ;)
By the way, of course users can also install both ffmpeg and libav-tools
and also packages build against ffmpeg and other packages build against
libav.
Adrian, do you agree that this is sane?
If the security team is not willing to support both, they can ask the TC
to decide which one to use, but this does not prevent an upload of FFmpeg.
I don't see why security would complain: as things stand there are
hundreds of security issues that have been fixed in ffmpeg (see the
Google audit) which have not been fixed in libav... It seems to me
ffmpeg is only more secure than libav at this point...
Previously, Moritz Mühlenhoff from the security team voiced his concerns
about having to apply security fixes for both [1]:
"But we still try to minimise such cases as much as possible. And for
libav/ffmpeg this simply isn't managable at all due to the huge stream
of security issues trickling in. We need definitely need to pick one
solution only."
I do not share these concerns, as there are e.g. mysql and mariadb
happily coexisting, but then again, I'm not on the security team.
But should they decide that it will not be possible to support both
packages for security updates, your argumentation would clearly favor
ffmpeg over libav, probably leading to the removal of libav from the
archive.
From my point of view this would be wrong, as I think the users and
developers should decide for themselves, which package they want to use,
and preventing one from being distributed in Debian only produces a
great amount of dissatisfaction and unhappiness among the users and
developers.
I think this package is ready for upload, but I'm neither DD nor DM, so
I can't do this.
I would be hesistant in doing so, considering the controversy, but if we
reach consensus here, i'd be happy to sponsor it.
As I understand it, the whole controversy here was about a conflict
between FFmpeg and libav due to having the same sonames. My packaging
avoids this, so the only remaining issue raised so far is the security
teams concern.
But if you have some time to review my packaging, I would be grateful
for any comments/improvements.
Best regards,
Andreas
1: https://lists.debian.org/debian-devel/2014/02/msg00668.html
--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debia
Bug#729203: Packaging for FFmpeg avoiding conflicts with libav
On 2014-02-22 12:39:20, Andreas Cadhalpun wrote: > Hi all, > > I have looked at the packaging provided by Antoine and it seems - no > offense intended - a little bit messy. Hehe, none taken. To my defense, I did that in about an hour, using Marillat's packages... :) > Thus I have started from scratch and packaged FFmpeg 2.1.3 [1] (see > attached debian.tar.xz). Awesome! > I have taken care to avoid conflicts with libav as far as possible, but > the development files have to conflict, as it is really no good idea to > build against both ffmpeg and libav at the same time. You mean the -dev libraries? > The ffmpeg package does not provide qt-faststart to avoid a conflict > with libav-tools. Fair enough - there could be a qt-faststart binary package which could conflict with libav-tools. > The libraries are build with --enable-raise-major, which bumps the > sonames by 100 to get i.e. libavcodec155, thus avoiding conflicts. > Note that there is also --enable-incompatible-libav-abi that would allow > packages build against libav to be used with the ffmpeg library, but > upstream thinks this would not work the other way round as well. And I > think there wouldn't be too much use for FFmpeg libraries that can only > be used as a drop in replacement the libav ones, but not to compile > programs. Makes sense. > As the libav development packages are called libavcodec-dev etc., FFmpeg > has to use different names and I chose libavcodec-ffmpeg-dev and so on. I guess that makes sense... > I'm not sure if this package will build on every architecture, because I > can't test that. Maybe an upload to experimental could test that? :) > Any build failures could probably be sorted out by disabling some > features for some architectures, as I enabled as many features as > possible for building on linux-amd64, as long as the result is still > GPLv2 licensed. (Only four codecs are GPLv3.) Makes sense as well. > I fixed most of the lintian problems, but some remain: > > * E: debian-watch-file-pubkey-file-is-missing: >This is a bug in lintian [2]. > * E: embedded-library: I don't understand this one: >Does it complain about libavfilter embedding libavfilter? >Seems like a bug in lintian. Not sure about those. > * W: manpage-has-errors-from-man: >I don't know how to fix the manpages. Can someone help? I had the manpage errors as well, I think we can ignore those for now. > * I: no-symbols-control-file: >If anyone wants to create one, feel free to do so. > > With this package, users can install either ffmpeg or libav-tools and > developers can either depend on lib*-ffmpeg-dev or on lib*-dev and > everyone should be happy. That would be awesome. > Adrian, do you agree that this is sane? > > If the security team is not willing to support both, they can ask the TC > to decide which one to use, but this does not prevent an upload of FFmpeg. I don't see why security would complain: as things stand there are hundreds of security issues that have been fixed in ffmpeg (see the Google audit) which have not been fixed in libav... It seems to me ffmpeg is only more secure than libav at this point... > I think this package is ready for upload, but I'm neither DD nor DM, so > I can't do this. I would be hesistant in doing so, considering the controversy, but if we reach consensus here, i'd be happy to sponsor it. > Rogério, Jackson are you willing to review my packaging and then > upload/maintain it? I can help e.g. rebuilding reverse-dependencies for > future transitions and similar stuff. > > In fact, If have rebuild the 109 reverse build-dependencies of src:libav > simply exchanging lib*-dev with lib*-ffmpeg-dev and 59 build > successfully, only 50 FTBFS (similarly many fail building with libav 10 > [3], probably due to the same reasons [4]). > Most failures are due to missing AVCODEC_MAX_AUDIO_FRAME_SIZE and > CodecID. Only two packages check for a version smaller than 100 and thus > fail to configure. > > I hope FFmpeg will be back in Debian soon. Good work, cheers! A. -- We have no friends but the mountains. - Kurdish saying pgpPs93E49Gzp.pgp Description: PGP signature
Bug#729203: Packaging for FFmpeg avoiding conflicts with libav
Hi all, I have looked at the packaging provided by Antoine and it seems - no offense intended - a little bit messy. Thus I have started from scratch and packaged FFmpeg 2.1.3 [1] (see attached debian.tar.xz). I have taken care to avoid conflicts with libav as far as possible, but the development files have to conflict, as it is really no good idea to build against both ffmpeg and libav at the same time. The ffmpeg package does not provide qt-faststart to avoid a conflict with libav-tools. The libraries are build with --enable-raise-major, which bumps the sonames by 100 to get i.e. libavcodec155, thus avoiding conflicts. Note that there is also --enable-incompatible-libav-abi that would allow packages build against libav to be used with the ffmpeg library, but upstream thinks this would not work the other way round as well. And I think there wouldn't be too much use for FFmpeg libraries that can only be used as a drop in replacement the libav ones, but not to compile programs. As the libav development packages are called libavcodec-dev etc., FFmpeg has to use different names and I chose libavcodec-ffmpeg-dev and so on. I'm not sure if this package will build on every architecture, because I can't test that. Any build failures could probably be sorted out by disabling some features for some architectures, as I enabled as many features as possible for building on linux-amd64, as long as the result is still GPLv2 licensed. (Only four codecs are GPLv3.) I fixed most of the lintian problems, but some remain: E: ffmpeg source: debian-watch-file-pubkey-file-is-missing W: ffmpeg: manpage-has-errors-from-man usr/share/man/man1/ffmpeg-all.1.gz 1267: warning [p 13, 2.5i, div `an-div', 0.2i]: can't break line W: ffmpeg: manpage-has-errors-from-man usr/share/man/man1/ffmpeg-filters.1.gz 273: warning [p 2, 9.2i]: can't break line W: ffmpeg: manpage-has-errors-from-man usr/share/man/man1/ffmpeg.1.gz 1267: warning [p 13, 2.5i, div `an-div', 0.2i]: can't break line W: ffmpeg: manpage-has-errors-from-man usr/share/man/man1/ffplay-all.1.gz 9728: warning [p 87, 11.8i]: can't break line W: ffmpeg: manpage-has-errors-from-man usr/share/man/man1/ffprobe-all.1.gz 10045: warning [p 73, 2.2i]: can't break line W: ffmpeg: manpage-has-errors-from-man usr/share/man/man1/ffserver-all.1.gz 9745: warning [p 85, 15.5i]: can't break line E: libavfilter103: embedded-library usr/lib/x86_64-linux-gnu/libavfilter.so.103.90.100: libavfilter I: libavfilter103: no-symbols-control-file usr/lib/x86_64-linux-gnu/libavfilter.so.103.90.100 E: libavdevice155: embedded-library usr/lib/x86_64-linux-gnu/libavdevice.so.155.5.100: libavdevice I: libavdevice155: no-symbols-control-file usr/lib/x86_64-linux-gnu/libavdevice.so.155.5.100 E: libpostproc152: embedded-library usr/lib/x86_64-linux-gnu/libpostproc.so.152.3.100: libpostproc I: libpostproc152: no-symbols-control-file usr/lib/x86_64-linux-gnu/libpostproc.so.152.3.100 I: libavcodec155: no-symbols-control-file usr/lib/x86_64-linux-gnu/libavcodec.so.155.39.101 I: libswscale102: no-symbols-control-file usr/lib/x86_64-linux-gnu/libswscale.so.102.5.101 E: libavutil152: embedded-library usr/lib/x86_64-linux-gnu/libavutil.so.152.48.101: libavutil I: libavutil152: no-symbols-control-file usr/lib/x86_64-linux-gnu/libavutil.so.152.48.101 I: libavformat155: no-symbols-control-file usr/lib/x86_64-linux-gnu/libavformat.so.155.19.104 I: libswresample100: no-symbols-control-file usr/lib/x86_64-linux-gnu/libswresample.so.100.17.104 * E: debian-watch-file-pubkey-file-is-missing: This is a bug in lintian [2]. * E: embedded-library: I don't understand this one: Does it complain about libavfilter embedding libavfilter? Seems like a bug in lintian. * W: manpage-has-errors-from-man: I don't know how to fix the manpages. Can someone help? * I: no-symbols-control-file: If anyone wants to create one, feel free to do so. With this package, users can install either ffmpeg or libav-tools and developers can either depend on lib*-ffmpeg-dev or on lib*-dev and everyone should be happy. Adrian, do you agree that this is sane? If the security team is not willing to support both, they can ask the TC to decide which one to use, but this does not prevent an upload of FFmpeg. I think this package is ready for upload, but I'm neither DD nor DM, so I can't do this. Rogério, Jackson are you willing to review my packaging and then upload/maintain it? I can help e.g. rebuilding reverse-dependencies for future transitions and similar stuff. In fact, If have rebuild the 109 reverse build-dependencies of src:libav simply exchanging lib*-dev with lib*-ffmpeg-dev and 59 build successfully, only 50 FTBFS (similarly many fail building with libav 10 [3], probably due to the same reasons [4]). Most failures are due to missing AVCODEC_MAX_AUDIO_FRAME_SIZE and CodecID. Only two packages check for a version smaller than 100 and thus fail to configure.
