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
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 alongside libav
On Feb 11, 2014 4:09 PM, "Antoine Beaupré" @ debian.org > wrote: > > On 2014-02-11 19:00:45, Timothy Gu wrote: > > On Feb 11, 2014 10:27 AM, "Antoine Beaupré" @ 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: ffmpeg alongside libav
On Feb 11, 2014 10:27 AM, "Antoine Beaupré" 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 packaging progress?
Hello, On Mon, Feb 10, 2014 at 8:50 PM, Antoine Beaupré 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: Fwd: Re: Bug#729203: CTTE and reasonable solutions
Sorry, forgot to CC bug tracker... -- Forwarded message -- From: "Timothy Gu" Date: Feb 3, 2014 3:32 PM Subject: Re: Bug#729203: CTTE and reasonable solutions To: "Adrian Bunk" Cc: On Feb 3, 2014 3:24 PM, "Adrian Bunk" 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: Fwd: Re: Bug#729203: CTTE and reasonable solutions
Sorry, forgot to CC bug tracker... -- Forwarded message -- From: "Timothy Gu" Date: Feb 3, 2014 3:56 PM Subject: Re: Bug#729203: CTTE and reasonable solutions To: "Jan Larres" Cc: > > On Feb 3, 2014 3:39 PM, "Jan Larres" 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" Date: Feb 3, 2014 3:28 PM Subject: Re: Bug#729203: CTTE and reasonable solutions To: "Antoine Beaupré" Cc: On Feb 3, 2014 3:12 PM, "Antoine Beaupré" 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: (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" > 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
