On Sat, Feb 22, 2014 at 11:18 AM, Andreas Cadhalpun <andreas.cadhal...@googlemail.com> 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-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org