Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Moritz Mühlenhoff]

Josselin Mouette  schrieb:
> Le jeudi 31 juillet 2014 à 22:19 +0200, Pau Garcia i Quiles a écrit :
>> How is it better to have libav, which does a lot less security
>> bugfixing, in?
>
>> I'd rather have a library that fixes bugs than one that passes in
>> order to look "more secure". When in fact it's less.
>
> I have no informed opinion on whether ffmpeg or libav is better. On the
> security front, it looks indeed like ffmpeg is doing better but it is
> still hearsay.

I think ffmpeg is doing better in terms of handling security issues; when
I contacted Michael Niedermeyer in private we has always quick to reply,
while libav-security@ seems understaffed: Several queries in the past needed
additional poking, some were left unaddressed until today. Also, the Google 
fuzzer guys stated that more samples are unfixed in libav compared to ffmpeg.

Cheers,
Moritz


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/slrnlts9a1.2k3@inutil.org

Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Josselin Mouette]

Le jeudi 31 juillet 2014 à 22:19 +0200, Pau Garcia i Quiles a écrit :
> How is it better to have libav, which does a lot less security
> bugfixing, in?

> I'd rather have a library that fixes bugs than one that passes in
> order to look "more secure". When in fact it's less.

I have no informed opinion on whether ffmpeg or libav is better. On the
security front, it looks indeed like ffmpeg is doing better but it is
still hearsay.

What I know, though, is that it is not realistic to maintain two such
libraries in the course of a stable release.

Said otherwise: if we have a consensus that ffmpeg is better, then let’s
do the switch NOW. Not after the freeze.

If it’s too late, libav will be the sole implementation in jessie, and
the switch will have to be done for jessie+1.

Cheers,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1406925100.13071.33.ca...@kagura.malsain.org

Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Ian Jackson]

Charles Plessy writes ("Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to 
Debian"):
> Le Thu, Jul 31, 2014 at 04:29:53PM -0700, Russ Allbery a écrit :
> > Based purely on security evaluations by others that I was able to find on
> > the web, FFmpeg appears to be better at the moment than libav on the
> > security front (although libav appears to be trying to catch up).
> 
> Hello everybody
> 
> At that point, and given the impressive number of users who
> expressed interest for having FFmpeg in Debian (see
> http://bugs.debian.org/729203), I think that it would be fair to ask
> the libav maintainers to provide arguments on whether to distribute
> both libraries or make a choice, even if it is against their own
> interest since they may see their packages removed at the end.
> 
> Otherwise we are in that kind of frequent Debianesque situation where the
> winning strategy is to stay silent as long as possible.

CCing libav@packages.d.o.

Ian.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21467.33652.506530.19...@chiark.greenend.org.uk

Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Nikolaus Rath]

Charles Plessy  writes:
> Le Thu, Jul 31, 2014 at 04:29:53PM -0700, Russ Allbery a écrit :
>> 
>> Based purely on security evaluations by others that I was able to find on
>> the web, FFmpeg appears to be better at the moment than libav on the
>> security front (although libav appears to be trying to catch up).
>
> Hello everybody
>
> At that point, and given the impressive number of users who expressed interest
> for having FFmpeg in Debian (see http://bugs.debian.org/729203), I think that
> it would be fair to ask the libav maintainers to provide arguments on whether
> to distribute both libraries or make a choice, even if it is against their own
> interest since they may see their packages removed at the end.
>
> Otherwise we are in that kind of frequent Debianesque situation where the
> winning strategy is to stay silent as long as possible.

>From what I have read about this situation now and in the past, I would
recommend to bring this to the CTTE right away and ask them to decide
whether the ffmpeg package in Debian should provide libav or ffmpeg.


I think it is unlikely that discussion between the concerned parties
will lead to a consensus, the jessie freeze is upcoming, and almost
every recent CTTE decision took several months. In other words, time is
running out, don't waste it with a pointless discussion on debian-devel.


Best,
Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/8738dgdc68@vostro.rath.org

Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Marco d'Itri]

On Aug 01, Russ Allbery  wrote:

> I personally don't have enough information to know why libav was chosen
> instead of FFmpeg, and the discussion on debian-devel so far has mostly
> come from FFmpeg advocates.  So there's probably another side to the story
> that hasn't been stated here yet.
Probably because there are no libav advocates other than the libav 
developers...

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Norbert Preining]

On Thu, 31 Jul 2014, Steve Langasek wrote:
> upstream conflict, but this is just wrong.  There is *nothing* unethical
> about reusing the library names and sonames when forking.  In fact, the

Besides, when changing APIs and breaking interaction with other
programs that rely on the original API.

You are right when the fork is API compatible (like extension of
a library that provides the same API plus something more), but 
*not* when changing the API.

In this case, me too, would consider it *incorrect* (I don't want to
use "unethical" as it is difficult to define).

Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140801010853.gp29...@auth.logic.tuwien.ac.at

Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Steve Langasek]

On Fri, Aug 01, 2014 at 01:50:26AM +0200, Pau Garcia i Quiles wrote:
> I'm all for forks but if you do a fork, at least you do it with ethics:
> different library names, sonames, etc.

I have nothing resembling an informed opinion on the libav vs. ffmpeg
upstream conflict, but this is just wrong.  There is *nothing* unethical
about reusing the library names and sonames when forking.  In fact, the
right to continue using such interfaces when creating a fork is a very
important principle.

There may have been a dispute over a domain name, and over which of two
upstream development communities is the "rightful" successor to the project. 
But the only party that "owns" the interface names in Debian is Debian
itself.  There are various /pragmatic/ reasons why we should care about how
each name is being used in the wider community, but that does not mean that
the side of the fork that keeps the domain name, that has a majority of mind
share, or that wins out in the end should be regarded as having a morally
superior claim *because* of this.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Pau Garcia i Quiles]

On Fri, Aug 1, 2014 at 1:29 AM, Russ Allbery  wrote:


> I personally don't have enough information to know why libav was chosen
> instead of FFmpeg, and the discussion on debian-devel so far has mostly
> come from FFmpeg advocates.  So there's probably another side to the story
> that hasn't been stated here yet.
>

libav was not chosen in Debian

ffmpeg had a leadership crisis a few years ago: Michael Niedermaier (who
has written here)  was accused of dictatorial methods by some ffmpeg
developers. I don't know if they were right or not in their complains and
frankly, I don't care.

Those guys tried a coup d'etat, stealing the domain, name, code repository,
logo and everything and leaving Michael out.  When Michael was able to
recover control of some things, and get a new hosting, source repository,
etc, they forked ffmpeg in libav. The libav guys knowingly tried and still
try to break ffmpeg by using the same library names and for a long time,
version numbers too.

The Debian maintainer of ffmpeg at the time (Reinhard, who has written here
too) was one of the guys who took the libav side instead of the ffmpeg
side. He used the ffmpeg package names to provide libav, and actively
blocked any effort that would lead to src:ffmpeg being actual ffmpeg.org.
That's why we have libav now instead of ffmpeg.

I'm all for forks but if you do a fork, at least you do it with ethics:
different library names, sonames, etc. The libav developers have tried from
minute zero to create a conflict. And what has been the outcome of that? A
library which worse than ffmpeg in features, codec support, security, and
essentially everything. As someone mentioned way back in the thread, the
only people who seem to prefer libav over ffmpeg are the libav developers.

I am not involved in libav or ffmpeg and if libav would be better
technically, in security, etc, I would be all for libav, even with all the
ill-intented methods they used. But it's not the case: they disrupt
peaceful open source communities (see this discussion, it's not the first
time in Debian and it has happened in other distributions too) with what
goal?... forcing a worse library in technical regards? OMG. Pointless.


-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)

Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Charles Plessy]

Le Thu, Jul 31, 2014 at 04:29:53PM -0700, Russ Allbery a écrit :
> 
> Based purely on security evaluations by others that I was able to find on
> the web, FFmpeg appears to be better at the moment than libav on the
> security front (although libav appears to be trying to catch up).

Hello everybody

At that point, and given the impressive number of users who expressed interest
for having FFmpeg in Debian (see http://bugs.debian.org/729203), I think that
it would be fair to ask the libav maintainers to provide arguments on whether
to distribute both libraries or make a choice, even if it is against their own
interest since they may see their packages removed at the end.

Otherwise we are in that kind of frequent Debianesque situation where the
winning strategy is to stay silent as long as possible.

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140731233851.gc28...@falafel.plessy.net

Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Russ Allbery]

Pau Garcia i Quiles  writes:

> So had the proposal been "hey, let's replace libav with ffmpeg", would
> you vote "yes" ? Only one library to maintain and review, and it happens
> to have good upstream support And replacing libav with ffmpeg is easy
> and the ffmpeg maintainer is committed to help port reverse
> dependencies. Looks good to me. Maybe Andreas should have made a
> not-so-polite proposal?

I personally don't have enough information to know why libav was chosen
instead of FFmpeg, and the discussion on debian-devel so far has mostly
come from FFmpeg advocates.  So there's probably another side to the story
that hasn't been stated here yet.

Based purely on security evaluations by others that I was able to find on
the web, FFmpeg appears to be better at the moment than libav on the
security front (although libav appears to be trying to catch up).

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/877g2trtse@windlord.stanford.edu

Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Pau Garcia i Quiles]

On Fri, Aug 1, 2014 at 12:41 AM, Russ Allbery  wrote:

> How is it better to have libav, which does a lot less security
> > bugfixing, in?
>
> It's not.
>
> However, what was proposed was having *both* of them, not dropping libav
> in favor of FFmpeg.
>

So had the proposal been "hey, let's replace libav with ffmpeg", would you
vote "yes" ? Only one library to maintain and review, and it happens to
have good upstream support And replacing libav with ffmpeg is easy and the
ffmpeg maintainer is committed to help port reverse dependencies. Looks
good to me. Maybe Andreas should have made a not-so-polite proposal?

-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)

Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Russ Allbery]

Pau Garcia i Quiles  writes:
> On Thu, Jul 31, 2014 at 9:54 PM, Josselin Mouette  wrote:

>> No FFmpeg security update is “minor”.

>> Almost each ffmpeg security bug is a code execution one. Almost each
>> and every one of them is hard to backport.

>> Those 10 security updates might represent more work than 100 *really*
>> minor security updates.

> How is it better to have libav, which does a lot less security
> bugfixing, in?

It's not.

However, what was proposed was having *both* of them, not dropping libav
in favor of FFmpeg.

-- 
Russ Allbery (r...@debian.org)   


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87tx5xrw0u@windlord.stanford.edu

Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Andreas Cadhalpun]

Hi Didier,

On 31.07.2014 22:36, Didier 'OdyX' Raboud wrote:

Le jeudi, 31 juillet 2014, 22.19:28 Pau Garcia i Quiles a écrit :

How is it better to have libav, which does a lot less security
bugfixing, in?


Our security team has to prepare the libav updates over the lifetime of
wheezy anyway.


As far as I know, both the updates for Libav and FFmpeg are prepared by 
their respective upstreams, then integrated into the Debian packages by 
the respective maintainers and only then comes work for the security 
team in reviewing the patches and writing a DSA.



Introducing ffmpeg in jessie (with or without dropping
libav) means (at least) duplicating that work.


Since all the updates for Libav are merged by FFmpeg, it's not really 
duplicated work. At least in theory only the additional fixes of FFmpeg 
would have to be reviewed additionally.


Best regards,
Andreas


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53dab016.2020...@googlemail.com

Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Andreas Cadhalpun]

Hi Josselin,

On 31.07.2014 21:54, Josselin Mouette wrote:

Le mercredi 30 juillet 2014 à 00:39 +0200, Andreas Cadhalpun a écrit :

I must have failed to make my point again. :(


No, you are the one who misunderstands the point.


Thanks for sharing your opinion.


As far as I know there are hundreds of security updates (for all
packages together) in the lifetime of a stable release. Compared to that
10 is not large. And, as I already mentioned, I think that some of the
FFmpeg updates are minor enough to go through stable-updates.


No FFmpeg security update is “minor”.


While it's hard to proof your statement, I agree that most of the FFmpeg 
security fixes should not be considered minor.
Still not every FFmpeg update (note that the word 'security' is absent 
here) fixes a severe security issue. Some contain only regression fixes. 
For example in the 2.2 release series, only 2.2.4 fixed a CVE, the other 
four updates did not, so could have gone through stable-updates.



Almost each ffmpeg security bug is a code execution one. Almost each and
every one of them is hard to backport.


When making such a statement it is very helpful to explain how you came 
to this conclusion.
For example, the last security fix (CVE-2014-4609) could be trivially 
backported even to the 0.5 branch. (I did so myself.)



Those 10 security updates might represent more work than 100 *really*
minor security updates.


Even if it required a lot of work to backport the security fixes, that 
work would be done by FFmpeg upstream anyway. The security team would at 
most have to review the changes.


Best regards,
Andreas


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53daae09.3000...@googlemail.com

Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Didier 'OdyX' Raboud]

Le jeudi, 31 juillet 2014, 22.19:28 Pau Garcia i Quiles a écrit :
> How is it better to have libav, which does a lot less security
> bugfixing, in?

Our security team has to prepare the libav updates over the lifetime of 
wheezy anyway. Introducing ffmpeg in jessie (with or without dropping 
libav) means (at least) duplicating that work.

OdyX


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5354151.iF7zqzrZRY@gyllingar

Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Pau Garcia i Quiles]

On Thu, Jul 31, 2014 at 9:54 PM, Josselin Mouette  wrote:


> No FFmpeg security update is “minor”.
>
> Almost each ffmpeg security bug is a code execution one. Almost each and
> every one of them is hard to backport.
>
> Those 10 security updates might represent more work than 100 *really*
> minor security updates.
>

How is it better to have libav, which does a lot less security bugfixing,
in?

I'd rather have a library that fixes bugs than one that passes in order to
look "more secure". When in fact it's less.

-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)

Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Josselin Mouette]

Le mercredi 30 juillet 2014 à 00:39 +0200, Andreas Cadhalpun a écrit :
> I must have failed to make my point again. :(

No, you are the one who misunderstands the point.

> As far as I know there are hundreds of security updates (for all 
> packages together) in the lifetime of a stable release. Compared to that 
> 10 is not large. And, as I already mentioned, I think that some of the 
> FFmpeg updates are minor enough to go through stable-updates.

No FFmpeg security update is “minor”.

Almost each ffmpeg security bug is a code execution one. Almost each and
every one of them is hard to backport.

Those 10 security updates might represent more work than 100 *really*
minor security updates.

Cheers,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1406836447.13071.3.ca...@kagura.malsain.org

Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Russ Allbery]

Thorsten Glaser  writes:

> As opposed to, for example, MySQL and Iceweasel, for which
> there is practically a blanket permission to upload new
> upstream releases unchecked into stable. (There appears to
> be one for Mediawiki and OpenJDK too, which do their security
> backporting themselves. This could apply to ffmpeg as well.)

Those are the ones I referenced where we're holding our nose and going
with a much less than ideal security policy because we don't have another
good option.  Those aren't packages that we can realistically drop from
the archive.

The same may apply to FFmpeg as well, but it's not a happy situation to be
in.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87oaw6j11y@windlord.stanford.edu

Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Thorsten Glaser]

Andreas Cadhalpun:

>So it's good that FFmpeg upstream does that backporting.

As opposed to, for example, MySQL and Iceweasel, for which
there is practically a blanket permission to upload new
upstream releases unchecked into stable. (There appears to
be one for Mediawiki and OpenJDK too, which do their security
backporting themselves. This could apply to ffmpeg as well.)

bye,
//mirabilos


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/lran33$9ve$2...@ger.gmane.org

Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Joseph Neal]

What we do to combat that is  All patches going into FFmpeg are

> reviewed with security in mind
>
> The codebase was repeatledly tested with fuzzed files to uncover all
> kinds of anomalies, all such found anomalies where fixed. Also
> independant of googles fuzzing efforts, some of our users have done
> their own fuzzing. And during google code in several students have as
> well manually tried to find security issues.
>
> FFmpeg is regularly tested with static code analyzsers like coverity
> and most issues found get quickly fixed
>
> FFmpeg is tested regularly with runtime memory checkers like
> valgrind, address sanitizer and others and all reproduceable issues
> are fixed, iam not aware of any open and reproduceable one
>
> Almost all of the internal APIs used in FFmpeg are designed to be
> secure, always passing array sizes and checking them instead of
> assuming the caller knows they are large enough, exceptions to this
> are just the most speed critical parts.
>
> Codecs which are WIP and arent up to security standards can be and
> are marked as experimental and will not be selected during
> autodetection unless overriden by the user.

Something else to add to this list is that ffmpeg has a far larger base 
of installed users bring the "more eyes" principle into play. I can't 
speak as to how many linux distros use which fork, though I believe the 
vast majority of all libav installs are debian and its derivatives.  
Ffmpeg, meanwhile, has a huge install base in the Windows and to a 
lessor degree Macintosh worlds as the backend to nearly every free video 
player or transcoder out there.   Virtually no upstreams with a choice 
are adopting libav, and I expect the number of those supporting it to 
dwindle as it continues drift away from ffmeg.


I don't see this as being much different from the 
imagemagik/graphicsmagic situation.


Sorry if my message formatting is screwed up.  I'm on windows and have 
no idea what I'm doing.

Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Michael Niedermayer]

On Wed, Jul 30, 2014 at 02:12:25AM +0200, Andreas Cadhalpun wrote:
> On 30.07.2014 00:54, Russ Allbery wrote:
> >Andreas Cadhalpun  writes:
> >
> >>I must have failed to make my point again. :(
> >>As far as I know there are hundreds of security updates (for all packages
> >>together) in the lifetime of a stable release. Compared to that 10 is not
> >>large. And, as I already mentioned, I think that some of the FFmpeg
> >>updates are minor enough to go through stable-updates.
> >
> >>It doesn't make a software less secure, if (even minor) security fixes get
> >>backported even to old release branches, rather the contrary.
> >
> >Well... backporting security fixes more of a bare minimum -- that's just
> >something that has to happen if we're going to support the software at
> >all, with a handful of exceptions where the software is, for one reason or
> >another, important enough that we're willing to release with it even
> >though security patches aren't backported properly and then terminate
> >support in the middle of our normal stable process.
> 
> So it's good that FFmpeg upstream does that backporting.
> 
> >But software should also not pose a significant security load in the first
> >place.  That quantity of security vulnerabilities tells me that something
> >is deeply wrong with FFmpeg as an upstream source base.  That's a sign of
> >code with a bad smell.
> 
> In my opinion the large amount of security fixes is due to the fact
> that FFmpeg is a large codebase and that most of the code has to
> deal with untrusted data, a.k.a. multimedia files.
> 
> >Now, that doesn't necessarily mean that it doesn't belong in Debian.
> >Sometimes we have to hold our nose and live with that, and it sounds like
> >libav isn't necessarily a lot better.
> 
> On the contrary I think that Libav is worse, as it doesn't even
> apply all patches for security vulnerabilities fixed in FFmpeg that
> also affect Libav. Just have a look at the security tracker of
> Libav[1].
> 
> > But those are really painful
> >statistics that, to me at least, indicate the world is crying out for a
> >replacement code base that accomplishes the same goals but was written
> >with a higher level of quality in mind.
> >
> >Obviously easier said than done, of course.
> 
> The time needed to do that would likely be spent a lot better with
> trying to find and fix the remaining vulnerabilities in FFmpeg,
> because any rewrite of such a large code base inevitably introduces
> it's own security bugs.
> 
> >Is upstream aware that this is a really bad track record and trying to do
> >something proactive to increase the quality of the code, like
> >comprehensive auditing, or proactive rewrites to use more secure coding
> >practices such as some of the work that the LibreSSL team has been doing?
> 
> On 30.07.2014 01:01, Russ Allbery wrote:
> > Ah, I should have Googled my own question.
> >
> > http://googleonlinesecurity.blogspot.com/2014/01/ffmpeg-and-thousand-fixes.html
> >
> > Well, that's... better than nothing.  It's certainly part of an
> > overall strategy, although that number of issues still indicates to
> > me that there are style and architecture issues here that could
> > benefit from more proactive design work.  I could be wrong, having
> > not looked at the code personally -- maybe the problem space is just
> > really hard.  But that seems like quite a lot of errors.
> 
> You could also have asked FFmpeg upstream. (I've CCed Michael
> Niedermayer now.)

Yes the problem space is hard ...
The problem with multimedia in relation to security is that
* There are hundreads of different formats, requireing alot of code
   to support them
* The input files and streams can generally not be trusted, which
   makes most of the code security relevant and a potential target for
   an exploit
* Many and especially the most important and efficient formats are
   very complex
* The code must be very fast, users want to see their movies play
   in realtime not waiting for each frame to be decoded. And most of
   the code is speed relevant

Above applies to any implementation, and constrains architecture
options ...

What we do to combat that is
All patches going into FFmpeg are reviewed with security in mind

The codebase was repeatledly tested with fuzzed files to uncover
all kinds of anomalies, all such found anomalies where fixed.
Also independant of googles fuzzing efforts, some of our users
have done their own fuzzing. And during google code in several
students have as well manually tried to find security issues.

FFmpeg is regularly tested with static code analyzsers like coverity
and most issues found get quickly fixed

FFmpeg is tested regularly with runtime memory checkers like
valgrind, address sanitizer and others and all reproduceable issues
are fixed, iam not aware of any open and reproduceable one

Almost all of the internal APIs used in FFmpeg are designed to be
secure, always passing array sizes and checking them instead of
assuming the call

Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Andreas Cadhalpun]

On 30.07.2014 00:54, Russ Allbery wrote:

Andreas Cadhalpun  writes:


I must have failed to make my point again. :(
As far as I know there are hundreds of security updates (for all packages
together) in the lifetime of a stable release. Compared to that 10 is not
large. And, as I already mentioned, I think that some of the FFmpeg
updates are minor enough to go through stable-updates.



It doesn't make a software less secure, if (even minor) security fixes get
backported even to old release branches, rather the contrary.


Well... backporting security fixes more of a bare minimum -- that's just
something that has to happen if we're going to support the software at
all, with a handful of exceptions where the software is, for one reason or
another, important enough that we're willing to release with it even
though security patches aren't backported properly and then terminate
support in the middle of our normal stable process.


So it's good that FFmpeg upstream does that backporting.


But software should also not pose a significant security load in the first
place.  That quantity of security vulnerabilities tells me that something
is deeply wrong with FFmpeg as an upstream source base.  That's a sign of
code with a bad smell.


In my opinion the large amount of security fixes is due to the fact that 
FFmpeg is a large codebase and that most of the code has to deal with 
untrusted data, a.k.a. multimedia files.



Now, that doesn't necessarily mean that it doesn't belong in Debian.
Sometimes we have to hold our nose and live with that, and it sounds like
libav isn't necessarily a lot better.


On the contrary I think that Libav is worse, as it doesn't even apply 
all patches for security vulnerabilities fixed in FFmpeg that also 
affect Libav. Just have a look at the security tracker of Libav[1].



 But those are really painful
statistics that, to me at least, indicate the world is crying out for a
replacement code base that accomplishes the same goals but was written
with a higher level of quality in mind.

Obviously easier said than done, of course.


The time needed to do that would likely be spent a lot better with 
trying to find and fix the remaining vulnerabilities in FFmpeg, because 
any rewrite of such a large code base inevitably introduces it's own 
security bugs.



Is upstream aware that this is a really bad track record and trying to do
something proactive to increase the quality of the code, like
comprehensive auditing, or proactive rewrites to use more secure coding
practices such as some of the work that the LibreSSL team has been doing?


On 30.07.2014 01:01, Russ Allbery wrote:
> Ah, I should have Googled my own question.
>
> 
http://googleonlinesecurity.blogspot.com/2014/01/ffmpeg-and-thousand-fixes.html

>
> Well, that's... better than nothing.  It's certainly part of an
> overall strategy, although that number of issues still indicates to
> me that there are style and architecture issues here that could
> benefit from more proactive design work.  I could be wrong, having
> not looked at the code personally -- maybe the problem space is just
> really hard.  But that seems like quite a lot of errors.

You could also have asked FFmpeg upstream. (I've CCed Michael 
Niedermayer now.)



I'm sympathetic to the concerns of the security team and the release team
about supporting two code bases with this much security activity in a
stable release.  Maybe it's still the right thing to do, but that's a lot
of work for them.


Of course I'm also sympathetic with the concerns of the security and 
release teams. But given that the alternatives are either to drop Libav, 
which the Libav maintainers would probably be unhappy about, or not 
having FFmpeg in the next stable release, which a lot of other people 
would be unhappy about, having both in stable seems like the least bad 
solution.


Best regards,
Andreas

1: https://security-tracker.debian.org/tracker/source-package/libav


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53d83869.90...@googlemail.com

Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Russ Allbery]

Russ Allbery  writes:

> Is upstream aware that this is a really bad track record and trying to
> do something proactive to increase the quality of the code, like
> comprehensive auditing, or proactive rewrites to use more secure coding
> practices such as some of the work that the LibreSSL team has been
> doing?

Ah, I should have Googled my own question.

http://googleonlinesecurity.blogspot.com/2014/01/ffmpeg-and-thousand-fixes.html

Well, that's... better than nothing.  It's certainly part of an overall
strategy, although that number of issues still indicates to me that there
are style and architecture issues here that could benefit from more
proactive design work.  I could be wrong, having not looked at the code
personally -- maybe the problem space is just really hard.  But that seems
like quite a lot of errors.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/874mxzhirj@windlord.stanford.edu

Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Russ Allbery]

Andreas Cadhalpun  writes:

> I must have failed to make my point again. :(
> As far as I know there are hundreds of security updates (for all packages
> together) in the lifetime of a stable release. Compared to that 10 is not
> large. And, as I already mentioned, I think that some of the FFmpeg
> updates are minor enough to go through stable-updates.

> It doesn't make a software less secure, if (even minor) security fixes get
> backported even to old release branches, rather the contrary.

Well... backporting security fixes more of a bare minimum -- that's just
something that has to happen if we're going to support the software at
all, with a handful of exceptions where the software is, for one reason or
another, important enough that we're willing to release with it even
though security patches aren't backported properly and then terminate
support in the middle of our normal stable process.

But software should also not pose a significant security load in the first
place.  That quantity of security vulnerabilities tells me that something
is deeply wrong with FFmpeg as an upstream source base.  That's a sign of
code with a bad smell.

Now, that doesn't necessarily mean that it doesn't belong in Debian.
Sometimes we have to hold our nose and live with that, and it sounds like
libav isn't necessarily a lot better.  But those are really painful
statistics that, to me at least, indicate the world is crying out for a
replacement code base that accomplishes the same goals but was written
with a higher level of quality in mind.

Obviously easier said than done, of course.

Is upstream aware that this is a really bad track record and trying to do
something proactive to increase the quality of the code, like
comprehensive auditing, or proactive rewrites to use more secure coding
practices such as some of the work that the LibreSSL team has been doing?

I'm sympathetic to the concerns of the security team and the release team
about supporting two code bases with this much security activity in a
stable release.  Maybe it's still the right thing to do, but that's a lot
of work for them.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87a97rhj3k@windlord.stanford.edu

Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Andreas Cadhalpun]

Hi Russ,

On 29.07.2014 23:30, Russ Allbery wrote:

Andreas Cadhalpun  writes:


Given the amount of software in Debian and thus the amount of security
fixes necessary for a stable release, I think that the additional
stable-security uploads for FFmpeg in the order of 10 per release will
be hardly noticeable.


Er, 8 security updates over the course of a stable release is already very
high.  Wouldn't adding another 10 make that the least secure source
package in Debian?  I believe that's worse than web browsers, which have a
very large attack surface and huge numbers of active and well-funded
attackers.  And this is just for a multimedia library.


I must have failed to make my point again. :(
As far as I know there are hundreds of security updates (for all 
packages together) in the lifetime of a stable release. Compared to that 
10 is not large. And, as I already mentioned, I think that some of the 
FFmpeg updates are minor enough to go through stable-updates.


It doesn't make a software less secure, if (even minor) security fixes 
get backported even to old release branches, rather the contrary.


Webbrowsers tend to have a lot more security issues and e.g. for Firefox 
15 security releases are planned in two years[2]. More importantly, 
Mozilla supports one release only for one year. That is much worse than 
the case of FFmpeg.
As e.g. the chromium browser uses FFmpeg[3] it is also under the 
scrutiny of the very same attackers and security researchers as webbrowsers.



I suppose it depends on how many of those could be grouped into one
update, and each Iceweasel update usually has multiple fixed CVEs, so
maybe this isn't an entirely fair comparison.  But still, those are
jaw-dropping numbers.


For the numbers of CVEs fixed in each FFmpeg release, please have a look 
at their security webpage[4]. Note how many of them get backported to 
old releases and if one isn't, that's probably because the old release 
didn't contain the vulnerable code.



While I understand and agree with the general idea of reducing code
duplication, I have a really hard time trying to understand why the
security team has such a strong opposition to the idea of having both
FFmpeg and Libav in Debian stable.


Because the sorts of numbers that you're talking about indicate that this
code is a complete security disaster.


Seen from a different point of view they show that the security support 
of FFmpeg is very good.



What is particularly hard for me to understand is why e.g. MySQL and
MariaDB can be in testing at the same time without much resistance from
the security team, but FFmpeg and Libav can apparently not.


MySQL is already a security update problem due to Oracle's very unhelpful
attitude towards security patches.  And we're still talking about rather
fewer security vulnerabilities than this, I believe.


So this gives me the impression that MySQL has a worse security support 
than FFmpeg, which doesn't really help to understand why the security 
team seems to be fine with having both forks of that in Debian testing.


Best regards,
Andreas


1: https://security-tracker.debian.org/tracker/source-package/libav
2: https://www.mozilla.org/en-US/firefox/organizations/faq/
3: 
https://src.chromium.org/svn/trunk/deps/third_party/ffmpeg/README.chromium

4: https://ffmpeg.org/security.html


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53d82293.7010...@googlemail.com

Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Russ Allbery]

Andreas Cadhalpun  writes:

> Given the amount of software in Debian and thus the amount of security
> fixes necessary for a stable release, I think that the additional
> stable-security uploads for FFmpeg in the order of 10 per release will
> be hardly noticeable.

Er, 8 security updates over the course of a stable release is already very
high.  Wouldn't adding another 10 make that the least secure source
package in Debian?  I believe that's worse than web browsers, which have a
very large attack surface and huge numbers of active and well-funded
attackers.  And this is just for a multimedia library.

I suppose it depends on how many of those could be grouped into one
update, and each Iceweasel update usually has multiple fixed CVEs, so
maybe this isn't an entirely fair comparison.  But still, those are
jaw-dropping numbers.

> While I understand and agree with the general idea of reducing code
> duplication, I have a really hard time trying to understand why the
> security team has such a strong opposition to the idea of having both
> FFmpeg and Libav in Debian stable.

Because the sorts of numbers that you're talking about indicate that this
code is a complete security disaster.

> What is particularly hard for me to understand is why e.g. MySQL and
> MariaDB can be in testing at the same time without much resistance from
> the security team, but FFmpeg and Libav can apparently not.

MySQL is already a security update problem due to Oracle's very unhelpful
attitude towards security patches.  And we're still talking about rather
fewer security vulnerabilities than this, I believe.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87ppgnhmym@windlord.stanford.edu

Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Andreas Cadhalpun]

On 29.07.2014 21:59, Raphael Geissert wrote:

On Tuesday 29 July 2014 18:43:17 Andreas Cadhalpun wrote:

On 29.07.2014 09:47, Raphael Geissert wrote:

Andreas Cadhalpun wrote:

According to the changelog[1], there have been 8 security updates for
ffmpeg in squeeze.


There would have been more


You're right, my calculation is slightly flawed.


That was my point, so please don't use it as an argument.


Maybe I didn't make my point clear enough, for which the actual number 
of the security uploads is not important, only the order of magnitude.


Given the amount of software in Debian and thus the amount of security 
fixes necessary for a stable release, I think that the additional 
stable-security uploads for FFmpeg in the order of 10 per release will 
be hardly noticeable.


While I understand and agree with the general idea of reducing code 
duplication, I have a really hard time trying to understand why the 
security team has such a strong opposition to the idea of having both 
FFmpeg and Libav in Debian stable.


One argument against code duplication is the risk that security issues 
get fixed in one, but not in the other. But in this particular case 
FFmpeg upstream merges all security fixes from Libav, so an FFmpeg 
package in a stable release won't have that problem.


What is particularly hard for me to understand is why e.g. MySQL and 
MariaDB can be in testing at the same time without much resistance from 
the security team, but FFmpeg and Libav can apparently not.



Not to mention that some bugs that are being
fixed are, for example, for incomplete checks - checks that don't exist
in the 0.5 branch.


What do you mean here? If the affected code is not there, then that's
nice, because a backport is not needed.


Let me rephrase it: the fix is for an incomplete check, but in 0.5 the check
is missing - while the rest of the code is there. Which is kinda... worse.


Now I see, what you mean. Indeed that's worse, but if one notices 
something like that, then the whole check can be backported instead of 
the change in the check.
Though it probably would have been better to backport already the 
incomplete check, when it was introduced in the development branch.


Best regards,
Andreas


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53d80eda.8040...@googlemail.com

Re: Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Raphael Geissert]

On Tuesday 29 July 2014 18:43:17 Andreas Cadhalpun wrote:
> On 29.07.2014 09:47, Raphael Geissert wrote:
> > Andreas Cadhalpun wrote:
> >> According to the changelog[1], there have been 8 security updates for
> >> ffmpeg in squeeze.
> > 
> > There would have been more
> 
> You're right, my calculation is slightly flawed.

That was my point, so please don't use it as an argument.

> > Not to mention that some bugs that are being
> > fixed are, for example, for incomplete checks - checks that don't exist
> > in the 0.5 branch.
> 
> What do you mean here? If the affected code is not there, then that's
> nice, because a backport is not needed.

Let me rephrase it: the fix is for an incomplete check, but in 0.5 the check 
is missing - while the rest of the code is there. Which is kinda... worse.

Cheers,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/38022338.xExGetmtcr@eee

Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Pau Garcia i Quiles]

On Tue, Jul 29, 2014 at 6:10 PM, Andreas Cadhalpun <
andreas.cadhal...@googlemail.com> wrote:


> I don't have an opinion about ffmpeg vs libav, apart from how hard the
>> soname transitions are, especially in ubuntu where we somehow ended up
>> with ex-multimedia packages around that either never were in debian,
>> or have been long removed from testing and/or unstable.
>>
>
> There are only 6 additional reverse-build-dependencies of src:libav in
> utopic. Two build against lib*-ffmpeg-dev without further changes, one
> needs a simple patch to use pkg-config, one needs a patch to adapt to newer
> API (also needed for Libav 10), one is BD-uninstallable and one fails for
> unrelated reasons, but its build-dependencies on libav*-dev seem to be
> unnecessary anyway.
>
> Per package list:
>
> alsa-plugins-extra: OK
> bombono-dvd: PATCH CodecID
> dvdstyler: Unmet build dependencies: libwxsvg-dev (>= 2:1.0.9)
> gstreamer-vaapi: error: unsupported GStreamer API version 1.4
> kffmpegthumbnailer: OK
> libdlna: PATCH pkg-config
>

In addition to this, I would like to note there is a lot of closed-source
software which uses ffmpeg instead of libav.

Not saying it doesn't exist but I don't know a single piece of
closed-source software which has moved from ffmpeg to libav.

I know, I know "non DFSG-free software, we don't care". Well, I do. E. g.
I'm having trouble with Qt right now because I'm using the commercial SDK
which indirectly uses ffmpeg to provide some codecs on Linux.

-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)

Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Andreas Cadhalpun]

Hi Raphael,

On 29.07.2014 09:47, Raphael Geissert wrote:

Andreas Cadhalpun wrote:

According to the changelog[1], there have been 8 security updates for
ffmpeg in squeeze.


There would have been more


You're right, my calculation is slightly flawed.


but the code has evolved too much for it to be
feasible to backport the patches.


That is likely true for some, but not for others.

The real reason that there have not been more security updates for 
ffmpeg in squeeze is that since 0.5.6 this is actually Libav and Libav 
upstream stopped providing backports to 0.5 after 0.5.10 in February 
2013 [1]. FFmpeg upstream released 0.5.14 in July 2014 [2] with some 
more fixes [3].


So had both been in squeeze, there would have been four more, i.e. 16 
security updates.



Not to mention that some bugs that are being
fixed are, for example, for incomplete checks - checks that don't exist in the
0.5 branch.


What do you mean here? If the affected code is not there, then that's 
nice, because a backport is not needed.


Best regards,
Andreas

1: https://www.libav.org/releases/
2: https://www.ffmpeg.org/releases/
3: 
https://git.videolan.org/?p=ffmpeg.git;a=shortlog;h=refs/heads/release/0.5



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53d7cf25.3040...@googlemail.com

Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Andreas Cadhalpun]

Hi Dimitri,

On 29.07.2014 03:12, Dimitri John Ledkov wrote:

I don't have an opinion about ffmpeg vs libav, apart from how hard the
soname transitions are, especially in ubuntu where we somehow ended up
with ex-multimedia packages around that either never were in debian,
or have been long removed from testing and/or unstable.


There are only 6 additional reverse-build-dependencies of src:libav in 
utopic. Two build against lib*-ffmpeg-dev without further changes, one 
needs a simple patch to use pkg-config, one needs a patch to adapt to 
newer API (also needed for Libav 10), one is BD-uninstallable and one 
fails for unrelated reasons, but its build-dependencies on libav*-dev 
seem to be unnecessary anyway.


Per package list:

alsa-plugins-extra: OK
bombono-dvd: PATCH CodecID
dvdstyler: Unmet build dependencies: libwxsvg-dev (>= 2:1.0.9)
gstreamer-vaapi: error: unsupported GStreamer API version 1.4
kffmpegthumbnailer: OK
libdlna: PATCH pkg-config

The patches are attached to this mail.


Thankfully, we
have worked to make sure libav is in universe only and thus is not a
security maintenance burden. Nonetheless, libav10 transition is still
not complete in utopic today.


Is bombono-dvd the last blocker?


I haven't checked, but now abi
compatible/incompatible the two stacks are? cause it would be a pain
if they are not drop in replacements, and it would also be a pain if
higher up packages link-in both ffmpeg & libav and some clashing
symbols are present...


As Marco already wrote, FFmpeg is packaged to be ABI incompatible with 
Libav, having different sonames and different symbol versions.



and people start requesting to have build
variants against both.


This could theoretically be done, but I don't think anyone wants to 
maintain such a thing, especially because it would need two different 
source packages, as the development packages of FFmpeg and Libav have to 
conflict.



Has a rebuild of all deps been done? How many
build failures there are? (On both debian & ubuntu, ideally) Is
hardening flags / toolchain enabled in both, or either of the two?


I did a rebuild of all the reverse-build-dependencies in sid and the 
results can be found in my original mail.

For Ubuntu, see the beginning of this mail.

I'm not sure what you want to know about hardening.
The packages are otherwise unchanged, so use hardening flags if they 
already do.
If that question was about FFmpeg/Libav, then yes, FFmpeg uses 
--toolchain=hardened and Libav hardening flags.


Best regards,
Andreas
diff --git a/debian/patches/CodecID.patch b/debian/patches/CodecID.patch
new file mode 100644
index 000..e85d2da
--- /dev/null
+++ b/debian/patches/CodecID.patch
@@ -0,0 +1,51 @@
+Description: Rename CodecID to AVCodecID
+
+Author: Andreas Cadhalpun 
+Last-Update: <2014-07-29>
+
+--- bombono-dvd-1.2.2.orig/src/mgui/ffviewer.cpp
 bombono-dvd-1.2.2/src/mgui/ffviewer.cpp
+@@ -62,7 +62,7 @@ C_LINKAGE_BEGIN
+ 
+ typedef struct AVCodecTag {
+ #if LIBAVFORMAT_VERSION_INT >= AV_VERSION_INT(52,39,00)
+-enum CodecID id;
++enum AVCodecID id;
+ #else
+ int id;
+ #endif
+@@ -70,14 +70,14 @@ typedef struct AVCodecTag {
+ } AVCodecTag;
+ 
+ #if LIBAVFORMAT_VERSION_INT >= AV_VERSION_INT(52,34,00)
+-static uint FFCodecID2Tag(CodecID codec_id) 
++static uint FFCodecID2Tag(AVCodecID codec_id) 
+ {
+ unsigned int ff_codec_get_tag(const AVCodecTag *tags, int id);
+ extern const AVCodecTag ff_codec_bmp_tags[];
+ return ff_codec_get_tag(ff_codec_bmp_tags, codec_id);
+ }
+ #else
+-static uint FFCodecID2Tag(CodecID codec_id) 
++static uint FFCodecID2Tag(AVCodecID codec_id) 
+ {
+ unsigned int codec_get_tag(const AVCodecTag *tags, int id);
+ extern const AVCodecTag codec_bmp_tags[];
+@@ -388,7 +388,7 @@ static unsigned char GetChar(uint tag, i
+ return (tag>>bit_begin) & 0xFF;
+ }
+ 
+-static std::string CodecID2Str(CodecID codec_id)
++static std::string CodecID2Str(AVCodecID codec_id)
+ {
+ #ifdef _MSC_VER
+ std::string tag_str = boost::format("%1%") % codec_id % bf::stop;
+@@ -406,7 +406,7 @@ static std::string CodecID2Str(CodecID c
+ 
+ #else // CALC_FF_TAG
+ 
+-static std::string CodecID2Str(CodecID codec_id)
++static std::string CodecID2Str(AVCodecID codec_id)
+ {
+ return Int2Str(codec_id);
+ }
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..03ff5cf
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+CodecID.patch
diff --git a/debian/control b/debian/control
index 4cd4492..a460e04 100644
--- a/debian/control
+++ b/debian/control
@@ -5,7 +5,7 @@ Maintainer: Ubuntu MOTU Developers 
 Uploaders: Alexis Saettler 
 XSBC-Original-Maintainer: Alexis Saettler 
 Homepage: http://libdlna.geexbox.org
-Build-Depends: debhelper (>= 7.0.50), libavcodec-dev (>= 4:0.6), libavformat-dev (>= 4:0.7)
+Build-Depends: debhelper (>= 7.0.50), libavcodec-dev (>= 4:0.6), libavformat-dev (>= 4:0.7), pkg-config
 Standards-Version: 3.8.0
 
 Package: libdlna-dev
diff --git a/de

Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Marco d'Itri]

On Jul 29, "\"IOhannes m zmölnig (Debian/GNU)\""  wrote:

> > This is why the new ffmpeg will use different symbols. Again, read 
> > the first message.
> according to the first message, this is *not* true.
It is:

- To avoid potential problems when a program is linked against
  FFmpeg libraries and other libraries, which in turn are linked
  against Libav, the symbol versions are changed to e.g.
  LIBAVCODEC_FFMPEG_55 instead of LIBAVCODEC_55.

https://lists.debian.org/debian-devel/2014/07/msg01010.html

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Raphael Geissert]

Andreas Cadhalpun wrote:
> According to the changelog[1], there have been 8 security updates for
> ffmpeg in squeeze. 

There would have been more but the code has evolved too much for it to be 
feasible to backport the patches. Not to mention that some bugs that are being 
fixed are, for example, for incomplete checks - checks that don't exist in the 
0.5 branch.



Cheers,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/lr7jjb$np3$1...@ger.gmane.org

Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[IOhannes m zmölnig (Debian/GNU)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2014-07-29 03:20, Marco d'Itri wrote:
>> if they are not drop in replacements, and it would also be a
>> pain if
>>> higher up packages link-in both ffmpeg & libav and some 
>>> clashing symbols are present...
> This is why the new ffmpeg will use different symbols. Again, read 
> the first message.
> 

according to the first message, this is *not* true.
the packages will have different libraries-names / sonames, but this
does not mean that they don't have clashing symbols.
if both library foo (/usr/lib/libfoo.so.3.21) and library bar
(/usr/lib/i386-linux-gnu/libbar.so.4.1) export the symbol "knarzifax",
then how do you make sure that an application that is linked against
both libraries for different functionality always chooses the korrect
"knarzifax"?

this becomes a real world issue, as soon as plugins are involved
(which i find a common practice to access multimedia frameworks).
application "flurp" has a both "flurp-plugin-libav" and
"flurp-plugin-ffmpeg" installed.
whichever plugin is loaded first, will pull in a library that shadows
the symbol "knarzifax" for the *other* plugin.

fgamsdr
IOhannes
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCAAGBQJT10jZAAoJELZQGcR/ejb4o1AP/3aoHeFNZ3xcOLl/I0Y9g5Fp
GsejeqWuE59CTtoo/1jp5byhueA5Uw9LpmFOmfKttKvqG3sEXhIkXBOA9wATXYS1
uDsblHzuhKhKagmkQ42N1Ql0h+d7vkZA8/duaAtcSb+8HOU/peMRUMQx/MQyxF4X
z8hrmSHMpd9S2QTFJxjIfFa0kCQ9gtBv+p/2BSCRpLkxQBDyCoZeHwTmNQnpac4S
xYT5Qzo2YW7U5JKXjllHoKcvdBJ1+gYJYfByBcn7ZmHVSv2Ittu9pl7kgH+S1KPk
kdK9mopt3B0riCnIR+m3467TJ4U/F/UQ5VuZwENZ5GqivyiqvHHyyWnf3T2aa+rC
hZM+k7mF06kQzOWcRi9F9Mqa/Tt0myZKYZVqpJY/y4U6LUYeSAcNmr6b0vzUkxh1
9YG3RwXMLNQZz565Dw7NoqO/7BKgoviSwSnd6OpHruGIYfScPQGkh0q9eU8v4q0U
wazXWQ9ks1hHmp4Ea5QJuT+S/BQv3I5QEW0QYXn6flUkDeyj+T27djBisugive7g
yGWEr4sVGczzwXjo1T5vgYxNGzvxPeBWGUzJqsRtxqVZKYYyMLYdzNA0TUP1B3vK
rQQJXi7oXDTt/ta7yp09Pbp3ZHqxkJbjpLibgYoY9g9dIsEab25jahIK5xRBytz1
6BtDVvwo6srTgQEqOjzw
=vaCN
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53d748dc.4010...@debian.org

Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Marco d'Itri]

On Jul 29, Dimitri John Ledkov  wrote:

> security maintenance burden. Nonetheless, libav10 transition is still
> not complete in utopic today. I haven't checked, but now abi
> compatible/incompatible the two stacks are? cause it would be a pain
They really are not, this was explained in detail in the first message.

> if they are not drop in replacements, and it would also be a pain if
> higher up packages link-in both ffmpeg & libav and some clashing
> symbols are present...
This is why the new ffmpeg will use different symbols. Again, read the 
first message.

> and people start requesting to have build variants against both.
I don't think so. The harsh reality is that the only people who love 
libav are the libav maintainers, so I expect that once ffmpeg will be 
available most maintainers will just switch their packages to it.

> Has a rebuild of all deps been done? How many
Yes, the data was in the first message.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Dimitri John Ledkov]

On 28 July 2014 15:05, Andreas Cadhalpun
 wrote:
> On 28.07.2014 13:52, Henrique de Moraes Holschuh wrote:
>>
>> On Mon, 28 Jul 2014, Norbert Preining wrote:
>>>
>>> On Sun, 27 Jul 2014, Reinhard Tartler wrote:

 In [1], Moritz from the security team clearly stated that he is more
 than uncomfortable with having more than one copy of libavcodec in
 debian/testing. In consequence this means that any package that builds

 against the ffmpeg packages currently in NEW won't make it into
 testing either. I am therefore surprised about the given answer to the
>>>
>>>
>>> "More than uncomfortable" does not mean "will not be included"
>>
>>
>> Yes, it does.
>>
>> Someone will have to convince the security team somehow, likely by
>> offering
>> to do the work themselves _and_ convincing them that these new members
>> will
>> be around for long enough.
>
>
> Michael Niedermayer from FFmpeg upstream volunteered "to help with any
> future security issues in FFmpeg packages in debian" [1].
>
>> However:
>>
>> The change in Debian-specific symbol versioning and sonames being done to
>> ffmpeg so that it is co-installable with libav *is* a problem.
>>
>> It has to be done in coordination with the Canonical guys, so that both
>> Debian and Ubuntu do the same thing re.  ffmpeg sonames and symbol
>> versioning.  Otherwise, the ffmpeg packages will be of very limited use
>> (useless to run third-party binary-only games ;-p).
>
>
> I don't think coordination with Ubuntu will be a problem.
> In comment #7 in the corresponding bug at launchpad [2] Dimitri John Ledkov
> wrote that Ubuntu won't introduce FFmpeg on it's on, but instead:
> "If you wish to see a supported ffmpeg stack in both Debian and Ubuntu,
> please become a developer and start maintaining it in Debian."

I don't have an opinion about ffmpeg vs libav, apart from how hard the
soname transitions are, especially in ubuntu where we somehow ended up
with ex-multimedia packages around that either never were in debian,
or have been long removed from testing and/or unstable. Thankfully, we
have worked to make sure libav is in universe only and thus is not a
security maintenance burden. Nonetheless, libav10 transition is still
not complete in utopic today. I haven't checked, but now abi
compatible/incompatible the two stacks are? cause it would be a pain
if they are not drop in replacements, and it would also be a pain if
higher up packages link-in both ffmpeg & libav and some clashing
symbols are present... and people start requesting to have build
variants against both. Has a rebuild of all deps been done? How many
build failures there are? (On both debian & ubuntu, ideally) Is
hardening flags / toolchain enabled in both, or either of the two?

-- 
Regards,

Dimitri.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/canbhluhhhjz7fk26we2qf1h2ss5ynfahwzqx8lfz7wbxsbk...@mail.gmail.com

Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Michael Niedermayer]

On Mon, Jul 28, 2014 at 04:05:46PM +0200, Andreas Cadhalpun wrote:
> On 28.07.2014 13:52, Henrique de Moraes Holschuh wrote:
> >On Mon, 28 Jul 2014, Norbert Preining wrote:
> >>On Sun, 27 Jul 2014, Reinhard Tartler wrote:
> >>>In [1], Moritz from the security team clearly stated that he is more
> >>>than uncomfortable with having more than one copy of libavcodec in
> >>>debian/testing. In consequence this means that any package that builds
> >>>against the ffmpeg packages currently in NEW won't make it into
> >>>testing either. I am therefore surprised about the given answer to the
> >>
> >>"More than uncomfortable" does not mean "will not be included"
> >
> >Yes, it does.
> >
> >Someone will have to convince the security team somehow, likely by offering
> >to do the work themselves _and_ convincing them that these new members will
> >be around for long enough.
> 

> Michael Niedermayer from FFmpeg upstream volunteered "to help with
> any future security issues in FFmpeg packages in debian" [1].

Yes, i do!

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus


signature.asc
Description: Digital signature

Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Andreas Cadhalpun]

On 28.07.2014 13:52, Henrique de Moraes Holschuh wrote:

On Mon, 28 Jul 2014, Norbert Preining wrote:

On Sun, 27 Jul 2014, Reinhard Tartler wrote:

In [1], Moritz from the security team clearly stated that he is more
than uncomfortable with having more than one copy of libavcodec in
debian/testing. In consequence this means that any package that builds
against the ffmpeg packages currently in NEW won't make it into
testing either. I am therefore surprised about the given answer to the


"More than uncomfortable" does not mean "will not be included"


Yes, it does.

Someone will have to convince the security team somehow, likely by offering
to do the work themselves _and_ convincing them that these new members will
be around for long enough.


Michael Niedermayer from FFmpeg upstream volunteered "to help with any 
future security issues in FFmpeg packages in debian" [1].



However:

The change in Debian-specific symbol versioning and sonames being done to
ffmpeg so that it is co-installable with libav *is* a problem.

It has to be done in coordination with the Canonical guys, so that both
Debian and Ubuntu do the same thing re.  ffmpeg sonames and symbol
versioning.  Otherwise, the ffmpeg packages will be of very limited use
(useless to run third-party binary-only games ;-p).


I don't think coordination with Ubuntu will be a problem.
In comment #7 in the corresponding bug at launchpad [2] Dimitri John 
Ledkov wrote that Ubuntu won't introduce FFmpeg on it's on, but instead:
"If you wish to see a supported ffmpeg stack in both Debian and Ubuntu, 
please become a developer and start maintaining it in Debian."


Best regards,
Andreas


1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729203#528
2: https://bugs.launchpad.net/ubuntu/+source/libav/+bug/1263278


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53d658ba.5090...@googlemail.com

Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Andreas Cadhalpun]

On 28.07.2014 13:24, Alessio Treglia wrote:

On Mon, Jul 28, 2014 at 12:12 PM, "IOhannes m zmölnig (Debian/GNU)"
 wrote:

Except that, for a lot of the depending packages, there would be an
  immediate benefit in the number of bugs fixed.


at least in theory.


Plus I would definitely appreciate to see some bug stats supporting
such a theory.


My original mail mentioned some examples.

Once FFmpeg is in the archive, each maintainer of a multimedia package 
could test build it against FFmpeg and see which, if any, of the bugs 
reported against said package vanish.


Best regards,
Andreas


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53d64f90.1020...@googlemail.com

Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[IOhannes m zmölnig (Debian/GNU)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

(resending, to keep debian-devel and the bug-report in the loop)

personally i would welcome if both libav and ffmpeg could co-exist
within Debian¹.
as i see it, libav and ffmpeg have diverged, and as such i would like
to have the choice which one to use.


On 2014-07-28 11:55, Marco d'Itri wrote:
> On Jul 28, Alessio Treglia  wrote:
> 
>> Personally I don't feel like dropping libav in favor of ffmpeg 
>> now at this stage.

+ 1
i don't think that dropping libav is appropriate at all.

> Except that, for a lot of the depending packages, there would be
> an immediate benefit in the number of bugs fixed.

at least in theory.


> Personally I feel that we have inflicted libav on our users for
> way more time than it was sensible to do.

i would appreciate it, if you (and anybody else) used a less flammable
&| touchy language.


fgmadr
IOhannes



¹ but then i'm not a member of the security team :-)

-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCAAGBQJT1jRXAAoJELZQGcR/ejb45GYP/2a06m3B6PRGyjV6oGS1xwDg
0if/Lssn500F8yjrYFKnexKGZg6xncKVKJ+NJncX3pIWMKu/fOXKJusC5Z5eMdvg
Ecruo7sXBojUnUxtaibGExkjdCWHv4wC/xwx/gQVUg3ijQGr5CQgZKXRPzf6dAG5
Sc4KS7w1SBtgLWaKvsOVhljSB39lye1cUk8vgkPkvSytJPiFMo1QSCDlbNz5JGbf
4c8viga5W9KCH5zMLzZTRQOkiPQpZMPsd/l220YX6ADwlBhnG/yRFBx7SBOnVDYb
BIWb4MFrsCikzC5gJrJZdVAkB96AWOWR6J8N0s8LI2Y1ZwOIM4nJB1FNeQvFRaJI
xe5p3dTI5DS7Kvc6i4LjKcO5m1EdZXeS1vV/OMDrLtgpfDC7pfhn3lImaYMPGCpA
60GNGo/PnbUMWGT3Z5JCeX/Q59X53d8DrW7gTcrQoSr6y0DN8AFEpcuDCYbd2ubt
/A+0MeocRPNKGiNB7lEfvpSD3x3e4pGlSFB1AMgnwCGmpXzHeA51LzbDJGtfdWon
x8L7OD5QD/LwRqQtAncRpf9jB56oJvktmznluSuCcJeY9ADSYH2YDPC1g3CCnuKG
SOJpSClZrPjlc2511emDcnOaMJhkyjeQ8R+I67+I05r0jBdk2FDnFASsNVVcRV5o
lzO+UTdVUs0nWsiDa+CX
=PGZV
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53d6345a.6050...@debian.org

Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Alessio Treglia]

On Mon, Jul 28, 2014 at 12:12 PM, "IOhannes m zmölnig (Debian/GNU)"
 wrote:
>> Except that, for a lot of the depending packages, there would be an
>>  immediate benefit in the number of bugs fixed.
>
> at least in theory.

Plus I would definitely appreciate to see some bug stats supporting
such a theory.

Cheers.

(IOhannes et Multimedia guys, please let's keep debian-devel in the
loop, I feel this is much more of general interest than a thing that
needs to be addressed internally in pkg-multimedia)

-- 
Alessio Treglia  | www.alessiotreglia.com
Debian Developer | ales...@debian.org
Ubuntu Core Developer|  quadris...@ubuntu.com
0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAMHuwowu6VQ85Xr-8W0d4rMDHWqF=nfxounncundfpzkgof...@mail.gmail.com

Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Andreas Cadhalpun]

Hi Julien,

On 28.07.2014 10:44, Julien Cristau wrote:

It remains to be seen, what the release team prefers: frustrated users and
developers or both forks in jessie.


The release team is likely to let the people involved in multimedia foo
fight it out among themselves and pick a winner.


I am not interested in a "fight" and would prefer it very much if this 
discussion remained purely technical.
Having a fresh memory of the last fight that took place on debian-devel, 
I do not think that repeating a similar disaster is a good idea.



 We're not going to ship both and hand that mess over to the security team.


Could you please explain what "mess" you are talking about?

According to the changelog[1], there have been 8 security updates for 
ffmpeg in squeeze. Two of them (4:0.5.6-2 and 4:0.5.6-3) do not contain 
security related fixes, but rather fix build failures of the previous 
security upload, so they do not really count.
That makes about 6 security fix uploads in about 3 years for squeeze, 
i.e. 1 upload per 6 month.


If there were both forks in Jessie, this might double the number of 
uploads to 12 in 3 years, but probably some of them could also go 
through stable-updates instead of stable-security.


Is that an unbearable burden?

A lot of other software in Debian has already alternatives, like desktop 
environments, web browsers, text editors and even init systems.


Why should this not be the case for a multimedia framework?

There is also one particularly similar case, as in the packages are 
forks and require many security updates:

MySQL and MariaDB are currently in Debian testing.

Just for comparison, MySQL in squeeze had 3 uploads to stable-security 
and 3 to oldstable(-security) [2].


As I mentioned this particular example in my discussion with Moritz, he 
said that the security team will "be working with the release

team to sort this out for jessie"[3].

Now, 5 months later, he seems to have changed his mind, as I am not 
aware of any such attempt, but instead Moritz seems to support both [4][5].


Thanks in advance for taking the time to answer these questions.

Best regards,
Andreas


1: 
http://metadata.ftp-master.debian.org/changelogs//main/f/ffmpeg/ffmpeg_0.5.10-1_changelog 

2: 
http://metadata.ftp-master.debian.org/changelogs//main/m/mysql-5.1/mysql-5.1_5.1.73-1_changelog

3: https://bugs.debian.org/729203#435
4: https://bugs.debian.org/754940
5: https://bugs.debian.org/754941


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53d62f9a.7040...@googlemail.com

Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Marco d'Itri]

On Jul 28, Alessio Treglia  wrote:

> Personally I don't feel like dropping libav in favor of ffmpeg now at
> this stage. It's too late for Jessie.
Except that, for a lot of the depending packages, there would be an 
immediate benefit in the number of bugs fixed.

Personally I feel that we have inflicted libav on our users for way more 
time than it was sensible to do.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Alessio Treglia]

Ciao,

On Mon, Jul 28, 2014 at 9:44 AM, Julien Cristau  wrote:
> The release team is likely to let the people involved in multimedia foo
> fight it out among themselves and pick a winner.  We're not going to
> ship both and hand that mess over to the security team.

Personally I don't feel like dropping libav in favor of ffmpeg now at
this stage. It's too late for Jessie.
Rather I'd suggest to start reconsidering such switch for Jessie+1.

Cheers.

-- 
Alessio Treglia  | www.alessiotreglia.com
Debian Developer | ales...@debian.org
Ubuntu Core Developer|  quadris...@ubuntu.com
0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAMHuwoz9xxOPmzprD=aa0xuZkk7Vj4puvJkKYa=9dkgu4jt...@mail.gmail.com

Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Julien Cristau]

On Mon, Jul 28, 2014 at 03:39:29 +0200, Andreas Cadhalpun wrote:

> Hi Reinhard,
> 
> On 28.07.2014 02:05, Reinhard Tartler wrote:
> >On Sun, Jul 27, 2014 at 7:20 PM, Andreas Cadhalpun
> > wrote:
> >
> >>  * Does it make sense for me to switch my package?
> >>The rule of thumb is, if your upstream uses FFmpeg for development
> >>you probably want to switch to using it, too.
> >
> >In [1], Moritz from the security team clearly stated that he is more
> >than uncomfortable with having more than one copy of libavcodec in
> >debian/testing.
> 
> I discussed this with Moritz in the ITP bug. Moritz ended this discussion
> [a], and as I wasn't convinced by his arguments, I continued my work. If in
> the end really only one copy is allowed in the next stable release, I think
> it should be FFmpeg.
> 
> >In consequence this means that any package that builds
> >against the ffmpeg packages currently in NEW won't make it into
> >testing either. I am therefore surprised about the given answer to the
> >question above.
> 
> It remains to be seen, what the release team prefers: frustrated users and
> developers or both forks in jessie.
> 
The release team is likely to let the people involved in multimedia foo
fight it out among themselves and pick a winner.  We're not going to
ship both and hand that mess over to the security team.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Andreas Cadhalpun]

Hi Reinhard,

On 28.07.2014 02:05, Reinhard Tartler wrote:

On Sun, Jul 27, 2014 at 7:20 PM, Andreas Cadhalpun
 wrote:


  * Does it make sense for me to switch my package?
The rule of thumb is, if your upstream uses FFmpeg for development
you probably want to switch to using it, too.


In [1], Moritz from the security team clearly stated that he is more
than uncomfortable with having more than one copy of libavcodec in
debian/testing.


I discussed this with Moritz in the ITP bug. Moritz ended this 
discussion [a], and as I wasn't convinced by his arguments, I continued 
my work. If in the end really only one copy is allowed in the next 
stable release, I think it should be FFmpeg.



In consequence this means that any package that builds
against the ffmpeg packages currently in NEW won't make it into
testing either. I am therefore surprised about the given answer to the
question above.


It remains to be seen, what the release team prefers: frustrated users 
and developers or both forks in jessie.



I think it would be best if ftp-master left the ffmpeg package in NEW
until an answer to this problem has been found.


I fail to see how this would help anyone, it only makes testing the 
package more difficult. Whether or not the package is acceptable for the 
next stable release is not to be decided by the ftp-masters, but rather 
by the release team.



[1] https://lists.debian.org/debian-devel/2014/02/msg00668.html


The FFmpeg version currently in NEW has been there for more than
2 months and is thus outdated. If you want to test the current
packages, you can build them from the repository on Alioth [17]
(e.g. using git-buildpackage).

Furthermore, we'd like to move the FFmpeg packaging under the umbrella
of the pkg-multimedia team, because this would facilitate future FFmpeg
transitions.


I am curious why this is your first email about this matter to
pkg-multimedia, and why do you write this email only now?


In the last discussion on debian-devel it was suggested to get the 
FFmpeg packages into experimental first [b], before further discussion, 
so I tried to achieve that.


As the package has been in NEW for a rather long time and the freeze is 
getting closer, sending this mail now seemed appropriate.



Moreover, I am curious why I haven't seen you working on libavcodec
bugs in Debian before,


It would be great if I could fix every bug in Debian, but unfortunately 
my time is limited. Therefore, when I encounter a problem that cannot 
immediately be fixed, I try to work around it. The workaround for 
practically all problems I had with the Libav packages in Debian could 
be solved by installing FFmpeg binaries from third parties. Therefore I 
finally decided to work on a more sustainable solution, i.e. a FFmpeg 
package in Debian.



and why do you believe you can do a better job
with the ffmpeg package currently on NEW?


It is a lot more likely that I work on fixing a bug that affects me, if 
there is no easy workaround.


Best regards,
Andreas


a: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729203#568
b: https://lists.debian.org/debian-devel/2014/02/msg00714.html


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53d5a9d1@googlemail.com