Bug#729203: Rebuild of possible FFmpeg reverse build-dependenciesa
On Apr 28, 2014 5:22 PM, Cyborg Ethly Alpha {My Research Desk}
cyborg.alpha.ch3...@gmail.com wrote:
On Lauchpad;
2: https://launchpad.net/ffmpeg-exp-nightly
The page says:
Licences: Creative Commons - No Rights Reserved, Other/Open Source
(A new license is being created FSL (FreeSpeechLicense) based on the
principles of GNU, OpenSource Free Speech.)
Huh? The Debian collab-maint ffmpeg package is GPL 2.0.
Timothy
Bug#729203: Packaging for FFmpeg avoiding conflicts with libav
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-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: ffmpeg packaging progress?
Hello, On Mon, Feb 10, 2014 at 8:50 PM, Antoine Beaupré anar...@debian.org wrote: Here it goes - I have been able to make a statically-built ffmpeg package that can be installed alongside libav harmlessly. It doesn't replace the libav libraries, so things like VLC and others still link against libav. This package doesn't exhibit bug #738599. I pushed this on github for now: https://github.com/anarcat/FFmpeg/tree/debian/debian This can allow people to build ffmpeg binaries reliably under Debian sid and jessie right now. It is currently non-free because if links against libfaac0 and so on. But it's a good start, I believe. This package is based on Marillat's ffmpeg packages, so it will need to import a lot of the improvements from the libav packages, amongst other things. There's a TODO in the debian/ directory explaining required work. Enjoy! I have experimented with the new --enable-rpath configure option of FFmpeg, and found that it is even possible to install shared libraries alongside Libav, without interrupting Libav headers, programs, or libraries. See my gist: https://gist.github.com/TimothyGu/8533059 I have also tried to build http://mpv.io/ with ffmpeg instead of libav, and I received success in doing tthat as well. Build script is in the gist as well. Timothy -- 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_w_yfoh1ejj39i8xmuajzkcmz8obcyryifr+qelgh1...@mail.gmail.com
Bug#729203: ffmpeg alongside libav
On Feb 11, 2014 10:27 AM, Antoine Beaupré anar...@debian.org wrote: On 2014-02-11 13:04:53, Timothy Gu wrote: I have experimented with the new --enable-rpath configure option of FFmpeg, and found that it is even possible to install shared libraries alongside Libav, without interrupting Libav headers, programs, or libraries. See my gist: https://gist.github.com/TimothyGu/8533059 Hum... isn't that because you install in /usr/local more than -rpath? I used /usr/local because if I mess up I can delete the installation completely. But it should work with /usr. Besides, -rpath is actually a lintian warning: http://lintian.debian.org/tags/binary-or-shlib-defines-rpath.html The page states that: The only time a binary or shared library in a Debian package should set RPATH is if it is linked to private shared libraries in the same package. In that case, place those private shared libraries in /usr/lib/*package*. That's exactly what's happening here if we'd like to add the ffmpeg programs but not use the libraries for other packages. Still, shared libraries are better than statically linking the ffmpeg programs. ... so we shouldn't use that, generally. I would rather try to check to see if we could sync the packages to make them ABI-compatible. I'd be interested in the results. I have also tried to build http://mpv.io/ with ffmpeg instead of libav, and I received success in doing tthat as well. Build script is in the gist as well. Thanks for sharing! That will certainly be useful for others. It should work for all applications wishing to support FFmpeg, including VLC. But the PKG_CONFIG_PATH is really not optimal. Timothy
Bug#729203: ffmpeg alongside libav
On Feb 11, 2014 4:09 PM, Antoine Beaupré anarcat anar...@debian.org@anar...@debian.org debian.org anar...@debian.org wrote: On 2014-02-11 19:00:45, Timothy Gu wrote: On Feb 11, 2014 10:27 AM, Antoine Beaupré anarcatanar...@debian.org @ anar...@debian.orgdebian.org anar...@debian.org wrote: On 2014-02-11 13:04:53, Timothy Gu wrote: I have also tried to build http:// http://mpv.io/mpv.io/http://mpv.io/ with ffmpeg instead of libav, and I received success in doing tthat as well. Build script is in the gist as well. Thanks for sharing! That will certainly be useful for others. It should work for all applications wishing to support FFmpeg, including VLC. But the PKG_CONFIG_PATH is really not optimal. That, and -rpath is designed for private libraries, so I don't think that could end up in the archive legitimately. To add ffmpeg to Debian, we have four options: 1. Make both programs and libraries available as a replacement for Libav. This would require full ABI, API, and behavior compatibility. This is the best if compatibilities are satisfied. 2. Use RPATH to make shared build libraries and programs and static libraries available. This is my solution for incompatible libraries. This way, ffmpeg programs can share libraries, and users who wish to use ffmpeg for other programs can compile the apps *themselves*, either dynamically or statically. The inconvenience of this method is mainly that a user must compile apps themselves. 3. Make only static libraries and programs available. This is your solution. This has several bad consequences comparing to #2: - ffmpeg programs would be too big. - a user cannot run two copies of a program that use either Libav/FFmpeg alongside each other. 4. Make FFmpeg the default in Debian. This is way too controversial, and if people still want Libav to be in Debian, #2 or #3 must be used because Libav is not trying to maintain compatibility with FFmpeg at all. A static link, on the other hand, may have a legitimate purpose. I don't see *any* advantages over RPATH except for silencing a few lintian warnings. People who wants to use FFmpeg libs still need to compile the app on their own. And if the static libs are installed to std locations it would cause more confusion as the static and shared libs in one directories are different. Timothy
Bug#729203: Fwd: Re: Bug#729203: CTTE and reasonable solutions
Sorry, forgot to CC bug tracker... -- Forwarded message -- From: Timothy Gu timothyg...@gmail.com Date: Feb 3, 2014 3:28 PM Subject: Re: Bug#729203: CTTE and reasonable solutions To: Antoine Beaupré anar...@debian.org Cc: On Feb 3, 2014 3:12 PM, Antoine Beaupré anar...@debian.org wrote: On 2014-02-03 17:13:43, Rogério Brito wrote: Rogério, I would suggest you go ahead with the packaging and an upload, don't let the flames fan your enthousiasm. Thanks for the encouragement, Antoine. I am mostly paralized with this situation and I don't really know how to proceed. I think that the forces of having to potentially fight the tech-ctte, the pkg-multimedia-team, the ftp-masters and some other people is that is preventing me right now from packaging ffmpeg all by myself. I am not sure you should fight anyone here. Do the package, may it policy-clean and it will pass NEW. If someone wants to bring up something with the ctte, they can do it, but you don't have to right now. Having a discussion on pkg-multimedia may be necessary if other package dependencies should be changed, and it is probably good practice to discuss this topic on that mailing list, but it seems to me that people shouldn't object to the inclusion of another package in debian solely on the ground that they do not like it. If both packages are ABI-compatible, then ffmpeg can be designed as a drop-in replacement for libav and users will be free to choose. Mostly, but even with FFmpeg's attempt, not entirely IIRC. I tried to use abi-compliance-checker once, but failed, and i didnt have much time to delve into how to use it. Also Debian's very own ABI checking program icheck has some bugs, ironically, on testing FFmpeg http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=427461. We have a policy for such procedures. Our social contract also says we should respond to the needs of users, and the overwhelming majority of people on this issue have voiced their need for a working ffmpeg implementation in Debian. We should respond to that. Exactly. [...] Timothy
Bug#729203: Fwd: Re: Bug#729203: CTTE and reasonable solutions
Sorry, forgot to CC bug tracker... -- Forwarded message -- From: Timothy Gu timothyg...@gmail.com Date: Feb 3, 2014 3:56 PM Subject: Re: Bug#729203: CTTE and reasonable solutions To: Jan Larres j...@majutsushi.net Cc: On Feb 3, 2014 3:39 PM, Jan Larres j...@majutsushi.net wrote: On 04/02/14 12:08, Antoine Beaupré wrote: If both packages are ABI-compatible, then ffmpeg can be designed as a drop-in replacement for libav and users will be free to choose. As far as I understand it the problem is that it is *not* a drop-in replacement as far as the libraries are concerned, every package needs to be recompiled depending on which library should be used. So you would need two different packages for every program that uses the libraries if you wanted to offer both in parallel. And I don't think Adrian (or anyone else) is against ffmpeg as such, it's just that there should be made a decision which one to use in order to avoid these issues. It's not as bad as you think. FFmpeg has a --enable-libav-incompatible-abi configure option. Didn't test the effectiveness of it though. Timothy Jan -- To unsubscribe, send mail to 729203-unsubscr...@bugs.debian.org.
Bug#729203: Fwd: Re: Bug#729203: CTTE and reasonable solutions
Sorry, forgot to CC bug tracker... -- Forwarded message -- From: Timothy Gu timothyg...@gmail.com Date: Feb 3, 2014 3:32 PM Subject: Re: Bug#729203: CTTE and reasonable solutions To: Adrian Bunk b...@stusta.de Cc: On Feb 3, 2014 3:24 PM, Adrian Bunk b...@stusta.de wrote: That is a mess, and would have to be sorted out by the Debian libav and ffmpeg maintainers before such an upload could happen. Agreed. But not exactly sure whether pkg-multimedia would want to collaborate... Timothy
Bug#729203: (no subject)
Hi Adrian,
Sorry if this is a duplicated mail because I forgot to CC the bug list.
On Jan 10, 2014 8:54 AM, Adrian Bunk b...@stusta.de javascript:_e({},
'cvml', 'b...@stusta.de'); wrote:
On Fri, Jan 10, 2014 at 08:17:45AM +0100, Lorenzo Sutton wrote:
Agree with many on at least providing the *option* for users to have
the original ffmpeg instead of libav and using sensible clear names
and descriptions for both packages.
...
Without getting into the politics of the fork etc. users should be
able to do
apt-get install ffmpeg
or
apr-get install libav
...
It is a misconception that making this optional would be a reasonable
solution - in reality the hassle that would create would is so huge
that no sane person would want to implement the packaging for something
like that.
Doing that for local use might not be too hard, but doing it 100%
correct for a Debian release is simply not feasible.
API/ABI sure is a problem, but please look at how Gentoo and potentially
some other distros do that (e.g. Homebrew).
Also in case you don't already know, FFmpeg tries very hard to preserve
both backwards and Libav compatibility. And this is essential to packagers.
Timothy
