Debian Bug report logs - #763148
Prevent migration to jessie

Package: ffmpeg; Maintainer for ffmpeg is Debian Multimedia Maintainers <debian-multimedia@lists.debian.org>; Source for ffmpeg is src:ffmpeg (PTS, buildd, popcon).

Reported by: Moritz Muehlenhoff <jmm@debian.org>

Date: Sun, 28 Sep 2014 08:27:02 UTC

Severity: serious

Tags: jessie, moreinfo

Done: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox

Report forwarded to debian-bugs-dist@lists.debian.org, Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>:
Bug#763148; Package ffmpeg. (Sun, 28 Sep 2014 08:27:07 GMT) (full text, mbox, link).

Acknowledgement sent to Moritz Muehlenhoff <jmm@debian.org>:
New Bug report received and forwarded. Copy sent to Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>. (Sun, 28 Sep 2014 08:27:07 GMT) (full text, mbox, link).

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

Package: ffmpeg
Severity: serious

As written before we can have only libav or ffmpeg in jessie.
I'm filing this blocker bug to prevent testing migration until
this is sorted out.

Cheers,
        Moritz

Information forwarded to debian-bugs-dist@lists.debian.org, Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>:
Bug#763148; Package ffmpeg. (Sun, 28 Sep 2014 09:30:19 GMT) (full text, mbox, link).

Acknowledgement sent to Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>:
Extra info received and forwarded to list. Copy sent to Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>. (Sun, 28 Sep 2014 09:30:19 GMT) (full text, mbox, link).

Message #10 received at 763148@bugs.debian.org (full text, mbox, reply):

Control: tag -1 moreinfo

On 28.09.2014 10:24, Moritz Muehlenhoff wrote:
> Package: ffmpeg
> Severity: serious
>
> As written before we can have only libav or ffmpeg in jessie.
> I'm filing this blocker bug to prevent testing migration until
> this is sorted out.

As I have explained [1], I see no security problem with having FFmpeg 
and Libav in Jessie, in particular because this is already the case for 
Wheezy, as chromium embeds a copy of FFmpeg.

So would you please explain why you see a problem?

Best regards,
Andreas

1: https://lists.debian.org/debian-release/2014/09/msg00452.html

Added tag(s) moreinfo. Request was from Andreas Cadhalpun <andreas.cadhalpun@googlemail.com> to 763148-submit@bugs.debian.org. (Sun, 28 Sep 2014 09:30:19 GMT) (full text, mbox, link).

Acknowledgement sent to Andreas Barth <aba@ayous.org>:
Extra info received and forwarded to list. Copy sent to Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>. (Sun, 28 Sep 2014 10:51:09 GMT) (full text, mbox, link).

Message #17 received at 763148@bugs.debian.org (full text, mbox, reply):

* Andreas Cadhalpun (andreas.cadhalpun@googlemail.com) [140928 11:27]:
> On 28.09.2014 10:24, Moritz Muehlenhoff wrote:
>> Package: ffmpeg
>> Severity: serious
>>
>> As written before we can have only libav or ffmpeg in jessie.
>> I'm filing this blocker bug to prevent testing migration until
>> this is sorted out.
>
> As I have explained [1], I see no security problem with having FFmpeg  
> and Libav in Jessie, in particular because this is already the case for  
> Wheezy, as chromium embeds a copy of FFmpeg.

First of all, I think it is very good news that we now have FFmpeg
available in Debian. Thank you for your work on it, it's appreciated.

However, the open question is (especially with the upcoming release),
do we want to have it in jessie? (That we probably want FFmpeg in
testing in the long run is something else, but the current discussion
is especially about jessie.)

I also think it's good that you actively raised this discussion, even
if it is perhaps not working as you would have like it. Please
continue this good style.

Another remark, we are already quite late in the cycle. At this point
it is too late to have greater changes to jessie. So even if jessie is
not officially frozen, larger changes are not possible anymore
(without disturbing the time plan).

> So would you please explain why you see a problem?

I hope we end this discussion on an agreement about the jessie plans.

However, to avoid misunderstandings at a later moment, I need to point
out that the final decision of what is part of jessie is taken by the
release team (or ultimatly the release managers). All of RC-bugs,
testing migration scripts etc are very valuable helpers because it
wouldn't be possible to manage it otherwise, but in the end they are
helpers.

The release policy does say "Packages must be security-supportable". I
would be surprised if a statement from the security team (assuming
that Moritz raised that bug report with his security team-hat on and
not privately) that they would like to have only one of libav and
ffmpeg in jessie would be overruled by the release team.

Now seeing the statements from the libav maintainers (which of course,
as this is an overlaping jurisdiction, could be escalated to the tech
ctte), that we already have transition freeze and the time planings
for jessie, makes it quite unlikely (or rather: impossible) to switch
from libav to FFmpeg in time for jessie. (Of course, for jessie+1
there is enough time for the transition. And for jessie+1 we will have
enough experience with FFmpeg in Debian to perhaps see things in a
different light.)

So from my experience I assume the final answer would look similar to
"It's too late for jessie, sorry". Which might be a pity but, well,
that's how it is.

Andi

Message #22 received at 763148@bugs.debian.org (full text, mbox, reply):

Hi,

On 28.09.2014 12:47, Andreas Barth wrote:
> * Andreas Cadhalpun (andreas.cadhalpun@googlemail.com) [140928 11:27]:
>> On 28.09.2014 10:24, Moritz Muehlenhoff wrote:
>>> Package: ffmpeg
>>> Severity: serious
>>>
>>> As written before we can have only libav or ffmpeg in jessie.
>>> I'm filing this blocker bug to prevent testing migration until
>>> this is sorted out.
>>
>> As I have explained [1], I see no security problem with having FFmpeg
>> and Libav in Jessie, in particular because this is already the case for
>> Wheezy, as chromium embeds a copy of FFmpeg.
>
> First of all, I think it is very good news that we now have FFmpeg
> available in Debian. Thank you for your work on it, it's appreciated.

Thank you for your kind words.

> However, the open question is (especially with the upcoming release),
> do we want to have it in jessie? (That we probably want FFmpeg in
> testing in the long run is something else, but the current discussion
> is especially about jessie.)

Yes, this is the open question. As you know, I would like to see FFmpeg 
in jessie. Many users want this as well [1]. It would also be good for 
XBMC and it would make it possible to have MPlayer in jessie.

> I also think it's good that you actively raised this discussion, even
> if it is perhaps not working as you would have like it. Please
> continue this good style.

It would indeed be nice if others would also follow this good style and 
participate constructively in the discussion instead of just blocking 
FFmpeg.

> Another remark, we are already quite late in the cycle. At this point
> it is too late to have greater changes to jessie. So even if jessie is
> not officially frozen, larger changes are not possible anymore
> (without disturbing the time plan).

This is nothing new for me, but letting FFmpeg migrate to jessie is no 
large change. It does not involve a transition of any kind.

>> So would you please explain why you see a problem?
>
> I hope we end this discussion on an agreement about the jessie plans.

That was my hope, when I started this discussion.

> However, to avoid misunderstandings at a later moment, I need to point
> out that the final decision of what is part of jessie is taken by the
> release team (or ultimatly the release managers). All of RC-bugs,
> testing migration scripts etc are very valuable helpers because it
> wouldn't be possible to manage it otherwise, but in the end they are
> helpers.

This is the reason why I contacted the release team.

> The release policy does say "Packages must be security-supportable". I
> would be surprised if a statement from the security team (assuming
> that Moritz raised that bug report with his security team-hat on and
> not privately) that they would like to have only one of libav and
> ffmpeg in jessie would be overruled by the release team.

Nonetheless both are in wheezy and will be in jessie, unless chromium 
gets removed from testing.
Debian policy § 4.13 [2] contains:
"Debian packages should not make use of these convenience copies unless 
the included package is explicitly intended to be used in this way.
If the included code is already in the Debian archive in the form of a 
library, the Debian packaging should ensure that binary packages 
reference the libraries already in Debian and the convenience copy is 
not used. If the included code is not already in Debian, it should be 
packaged separately as a prerequisite if possible."

FFmpeg is not intended to be used as embedded code copy, yet chromium 
uses it that way. It should instead use the system libraries, which are 
now available.
I absolutely cannot understand why the security team would prefer to 
have an embedded code copy instead of a properly packaged library.

> Now seeing the statements from the libav maintainers (which of course,
> as this is an overlaping jurisdiction, could be escalated to the tech
> ctte), that we already have transition freeze and the time planings
> for jessie, makes it quite unlikely (or rather: impossible) to switch
> from libav to FFmpeg in time for jessie. (Of course, for jessie+1
> there is enough time for the transition. And for jessie+1 we will have
> enough experience with FFmpeg in Debian to perhaps see things in a
> different light.)

As I have made clear from the beginning [3], I see no need for a 
transition as long as Libav is maintained.
The purpose of having FFmpeg is that users can use the binary tools and 
that developers can use the libraries, if they want to.

> So from my experience I assume the final answer would look similar to
> "It's too late for jessie, sorry". Which might be a pity but, well,
> that's how it is.

It is too late for a transition, but it is not too late for letting 
FFmpeg migrate into testing.

Best regards,
Andreas

1: 
https://qa.debian.org/popcon-graph.php?packages=libavutil-ffmpeg54&show_installed=on&want_legend=on&want_ticks=on&from_date=&to_date=&hlght_date=&date_fmt=%25m-%25d&beenhere=1
2: https://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles
3: https://lists.debian.org/debian-devel/2014/07/msg01010.html

Message #27 received at 763148@bugs.debian.org (full text, mbox, reply):

* Andreas Cadhalpun (andreas.cadhalpun@googlemail.com) [140928 14:36]:
> On 28.09.2014 12:47, Andreas Barth wrote:

>> The release policy does say "Packages must be security-supportable". I
>> would be surprised if a statement from the security team (assuming
>> that Moritz raised that bug report with his security team-hat on and
>> not privately) that they would like to have only one of libav and
>> ffmpeg in jessie would be overruled by the release team.
>
> Nonetheless both are in wheezy and will be in jessie, unless chromium  
> gets removed from testing.

There is a distinction between an old and a new package.

However (and please note that I'm not a member of the security team
and just speak for myself here as always when not otherwise marked) if
it would be possible to replace the internal code copy in chromium
by a reference to ffmpeg (but it's not possible with libav), that will
probably lead to a re-evalutation. (That doesn't necessarily mean
"sucess guranteed", but it looks to me as it will not make things
worse.)

Perhaps you always intended that, but at least I didn't understand it
that way yet.

> I absolutely cannot understand why the security team would prefer to  
> have an embedded code copy instead of a properly packaged library.

I don't think they do that. However, I can understand why one embedded
code copy is better than one embedded code copy plus a library in
addition to it.

Andi

Added tag(s) sid and jessie. Request was from Holger Levsen <holger@layer-acht.org> to control@bugs.debian.org. (Tue, 30 Sep 2014 08:54:06 GMT) (full text, mbox, link).

Information forwarded to debian-bugs-dist@lists.debian.org, Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>:
Bug#763148; Package ffmpeg. (Tue, 30 Sep 2014 20:48:19 GMT) (full text, mbox, link).

Acknowledgement sent to Moritz Mühlenhoff <jmm@inutil.org>:
Extra info received and forwarded to list. Copy sent to Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>. (Tue, 30 Sep 2014 20:48:19 GMT) (full text, mbox, link).

Message #34 received at 763148@bugs.debian.org (full text, mbox, reply):

On Sun, Sep 28, 2014 at 11:27:03AM +0200, Andreas Cadhalpun wrote:
> So would you please explain why you see a problem?

It has all been written before, I'm not going to repeat
it all over again. We can pick libav _or_ ffmpeg for jessie+1.
EOD for me.

Chromium using a local copy of the lib doesn't matter in
practice since we need to spin updates for the browser
security bugs anyway.

Cheers,
        Moritz

Acknowledgement sent to Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>:
Extra info received and forwarded to list. Copy sent to Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>. (Tue, 30 Sep 2014 23:03:04 GMT) (full text, mbox, link).

Message #39 received at 763148@bugs.debian.org (full text, mbox, reply):

Hi Moritz,

On 30.09.2014 22:45, Moritz Mühlenhoff wrote:
> On Sun, Sep 28, 2014 at 11:27:03AM +0200, Andreas Cadhalpun wrote:
>> So would you please explain why you see a problem?
>
> It has all been written before, I'm not going to repeat
> it all over again. We can pick libav _or_ ffmpeg for jessie+1.

The above doesn't contain any explanation, why you think FFmpeg can't be 
supported in jessie. It does not even contain a pointer to where such an 
explanation has supposedly been written before.

> EOD for me.

You made similar statements before and I must say that they are not part 
of what I consider a constructive discussion.

I only remember two mails in which you provided some arguments against 
having both:
In the early discussion on debian-devel you wrote [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."

The first sentence is about the general goal of reducing code 
duplication, which I agree with, because duplicated code copies usually 
make it harder to fix security issues.
But in the case of FFmpeg and Libav, this is not really a problem, 
because FFmpeg upstream merges all security fixes from Libav.
And if chromium would use the system FFmpeg libraries instead of the 
embedded FFmpeg copy, the overall code duplication wouldn't increase.

Then you continued that supporting FFmpeg in addition to Libav would not 
be possible due to the huge amount of security fixes.
But FFmpeg had only 7 CVEs in 2014, while e.g. MySQL had 37 and chromium 
had 64, which are much larger numbers.

In the FFmpeg ITP bug you stated [2]:
"Exactly. It makes it really easy to not share concerns if you're not
affected by the work imposed from the decision. "

While it is true that I'm not part of the security team, I would still 
be the one to actually package the upstream security fixes for FFmpeg. 
The security team would only have to review those and send out a DSA.

> Chromium using a local copy of the lib doesn't matter in
> practice since we need to spin updates for the browser
> security bugs anyway.

So for chromium code duplication doesn't matter?
Debian policy doesn't matter?
And it doesn't matter because chromium needs so many security fixes that 
a few more don't hurt?

This completely contradicts what you wrote in [1] with regard to code 
duplication and also with regard to the supposedly huge amount of 
security fixes for FFmpeg.

As I have explained multiple times before, I don't see how your 
arguments would be sufficient for blocking FFmpeg from jessie.

Best regards,
Andreas

1: https://lists.debian.org/debian-devel/2014/02/msg00668.html
2: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729203#435
3: https://security-tracker.debian.org/tracker/source-package/ffmpeg
4: 
https://security-tracker.debian.org/tracker/source-package/chromium-browser

Information forwarded to debian-bugs-dist@lists.debian.org, Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>:
Bug#763148; Package ffmpeg. (Wed, 01 Oct 2014 14:36:05 GMT) (full text, mbox, link).

Acknowledgement sent to Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>:
Extra info received and forwarded to list. Copy sent to Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>. (Wed, 01 Oct 2014 14:36:05 GMT) (full text, mbox, link).

Message #44 received at 763148@bugs.debian.org (full text, mbox, reply):

Hi,

On 28.09.2014 14:44, Andreas Barth wrote:
> * Andreas Cadhalpun (andreas.cadhalpun@googlemail.com) [140928 14:36]:
>> On 28.09.2014 12:47, Andreas Barth wrote:
>
>>> The release policy does say "Packages must be security-supportable". I
>>> would be surprised if a statement from the security team (assuming
>>> that Moritz raised that bug report with his security team-hat on and
>>> not privately) that they would like to have only one of libav and
>>> ffmpeg in jessie would be overruled by the release team.
>>
>> Nonetheless both are in wheezy and will be in jessie, unless chromium
>> gets removed from testing.
>
> There is a distinction between an old and a new package.

I don't think that makes a difference from a security point of view.

> However (and please note that I'm not a member of the security team
> and just speak for myself here as always when not otherwise marked) if
> it would be possible to replace the internal code copy in chromium
> by a reference to ffmpeg

I have created a patch for that and opened bug #763632 [1].

> (but it's not possible with libav),

Chromium can't work with Libav, because, similar to MPlayer, it uses 
features of FFmpeg, which are not available in Libav, e.g. 
av_buffer_get_opaque.

> that will
> probably lead to a re-evalutation. (That doesn't necessarily mean
> "sucess guranteed", but it looks to me as it will not make things
> worse.)

Then please start this re-evaluation now.

> Perhaps you always intended that, but at least I didn't understand it
> that way yet.

Yes, that was what I intended.

>> I absolutely cannot understand why the security team would prefer to
>> have an embedded code copy instead of a properly packaged library.
>
> I don't think they do that.

How do you interpret the last message from Moritz then?
"Chromium using a local copy of the lib doesn't matter" [2]

> However, I can understand why one embedded
> code copy is better than one embedded code copy plus a library in
> addition to it.

This would be understandable, yes.

There are now two options:
a) Let FFmpeg migrate to testing and make chromium use it.
b) Don't let FFmpeg migrate and let chromium continue to use the
   embedded copy, in spite of the policy violation.
   If this really would be preferred, then the FFmpeg libraries and
   tools could be build from the chromium source package, because that
   can't increase the security workload, as the source is already in
   wheezy.

If you ask me, only one of these options is a sane thing to do.

Best regards,
Andreas

1: https://bugs.debian.org/763632
2: https://bugs.debian.org/763148#34

Information forwarded to debian-bugs-dist@lists.debian.org, Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>:
Bug#763148; Package ffmpeg. (Thu, 02 Oct 2014 16:48:17 GMT) (full text, mbox, link).

Acknowledgement sent to Moritz Mühlenhoff <jmm@inutil.org>:
Extra info received and forwarded to list. Copy sent to Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>. (Thu, 02 Oct 2014 16:48:17 GMT) (full text, mbox, link).

Message #49 received at 763148@bugs.debian.org (full text, mbox, reply):

On Wed, Oct 01, 2014 at 04:32:24PM +0200, Andreas Cadhalpun wrote:
> >However, I can understand why one embedded
> >code copy is better than one embedded code copy plus a library in
> >addition to it.
> 
> This would be understandable, yes.
> 
> There are now two options:
> a) Let FFmpeg migrate to testing and make chromium use it.
> b) Don't let FFmpeg migrate and let chromium continue to use the
>    embedded copy, in spite of the policy violation.
>    If this really would be preferred, then the FFmpeg libraries and
>    tools could be build from the chromium source package, because that
>    can't increase the security workload, as the source is already in
>    wheezy.

Chromium is actually a special case. It's a huge monster package which is 
very difficult to integrate and maintain. 
You seem to have missed that for Chromium we rebuild the current upstream 
releases in stable. Since there're not guarantees for any kind of API stability in
the local ffmpeg copy that is obviously not a good idea.

Cheers,
        Moritz

Acknowledgement sent to Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>:
Extra info received and forwarded to list. Copy sent to Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>. (Thu, 02 Oct 2014 17:21:15 GMT) (full text, mbox, link).

Message #54 received at 763148@bugs.debian.org (full text, mbox, reply):

Hi Moritz,

On 02.10.2014 18:43, Moritz Mühlenhoff wrote:
> On Wed, Oct 01, 2014 at 04:32:24PM +0200, Andreas Cadhalpun wrote:
>>> However, I can understand why one embedded
>>> code copy is better than one embedded code copy plus a library in
>>> addition to it.
>>
>> This would be understandable, yes.
>>
>> There are now two options:
>> a) Let FFmpeg migrate to testing and make chromium use it.
>> b) Don't let FFmpeg migrate and let chromium continue to use the
>>     embedded copy, in spite of the policy violation.
>>     If this really would be preferred, then the FFmpeg libraries and
>>     tools could be build from the chromium source package, because that
>>     can't increase the security workload, as the source is already in
>>     wheezy.
>
> Chromium is actually a special case. It's a huge monster package which is
> very difficult to integrate and maintain.

One of the reasons that make it difficult to integrate is that it embeds 
many other projects. (The third_party folder in the chromium source tree 
contains 150 subfolders!)
From chromium's debian/rules one can see that the chromium maintainers 
try to use system libraries wherever possible, e.g. for bzip2, libjpeg, 
libpng and so on. It also already contains (outdated) support for using 
system FFmpeg libraries, but using that was not possible, because FFmpeg 
hadn't been available in Debian since squeeze until very recently.
So I hope the maintainer of chromium is now happy to be able to use more 
system libraries.

> You seem to have missed that for Chromium we rebuild the current upstream
> releases in stable.

I was aware of that and as I understand it, this is not something the 
security team likes very much.

> Since there're not guarantees for any kind of API stability in
> the local ffmpeg copy that is obviously not a good idea.

Great that we agree on b) being no good idea.

So can we now go forward with a) by letting FFmpeg migrate to testing?

Best regards,
Andreas

Information forwarded to debian-bugs-dist@lists.debian.org, Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>:
Bug#763148; Package ffmpeg. (Fri, 03 Oct 2014 00:12:15 GMT) (full text, mbox, link).

Acknowledgement sent to Michael Gilbert <mgilbert@debian.org>:
Extra info received and forwarded to list. Copy sent to Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>. (Fri, 03 Oct 2014 00:12:15 GMT) (full text, mbox, link).

Message #59 received at 763148@bugs.debian.org (full text, mbox, reply):

On Thu, Oct 2, 2014 at 1:16 PM, Andreas Cadhalpun wrote:
> So I hope the maintainer of chromium is now happy to be able to use more
> system libraries.

chromium moves way too fast to take advantage of any stable ffmpeg
api.  As soon as a new ffmpeg is out, they use it whether it breaks
abi/api or not, so it's unsupportable to dynamically link over a
stable release lifetime.

Best wishes,
Mike

Acknowledgement sent to Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>:
Extra info received and forwarded to list. Copy sent to Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>. (Fri, 03 Oct 2014 17:48:08 GMT) (full text, mbox, link).

Message #64 received at 763148@bugs.debian.org (full text, mbox, reply):

Hi Michael,

On 03.10.2014 02:10, Michael Gilbert wrote:
> On Thu, Oct 2, 2014 at 1:16 PM, Andreas Cadhalpun wrote:
>> So I hope the maintainer of chromium is now happy to be able to use more
>> system libraries.
>
> chromium moves way too fast to take advantage of any stable ffmpeg
> api.

How did you come to this conclusion?

>  As soon as a new ffmpeg is out, they use it whether it breaks
> abi/api or not,

Yet the currently packaged chromium embeds a version of FFmpeg from 
around May this year, i.e. approximately lagging two upstream versions 
behind.

The ABI won't be a problem, when chromium is built against system 
FFmpeg. (Unless it is broken on purpose, see e.g. 
fix_for_system_ffmpeg_ABI.patch.)

So only API changes could cause problems, but e.g. adapting chromium to 
the current FFmpeg version is quite trivial.

And chromium doesn't really use brand new FFmpeg API, e.g. the newest 
two functions used are from July and March 2013.

> so it's unsupportable to dynamically link over a
> stable release lifetime.

In the case that chromium starts using newer API during the lifetime of 
a stable release, there are several options to handle that:
 * revert to the old API
 * disable new features
 * add the needed functionality to FFmpeg
 * or as a last resort, disable using the system FFmpeg

I'm quite confident that we would come up with a sensible solution, if 
such a problem would arise.

But I don't think that the mere possibility of such problems is a 
sufficient reason to disregard Debian policy, which clearly states that 
embedded code copies should not be used.
This is especially the case, if it prevents the properly packaged 
library and the command line tools from being part of the stable release.

Best regards,
Andreas

Information forwarded to debian-bugs-dist@lists.debian.org, Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>:
Bug#763148; Package ffmpeg. (Sun, 05 Oct 2014 01:30:05 GMT) (full text, mbox, link).

Acknowledgement sent to Michael Gilbert <mgilbert@debian.org>:
Extra info received and forwarded to list. Copy sent to Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>. (Sun, 05 Oct 2014 01:30:05 GMT) (full text, mbox, link).

Message #69 received at 763148@bugs.debian.org (full text, mbox, reply):

On Fri, Oct 3, 2014 at 1:44 PM, Andreas Cadhalpun wrote:
> But I don't think that the mere possibility of such problems is a sufficient
> reason to disregard Debian policy, which clearly states that embedded code
> copies should not be used.
> This is especially the case, if it prevents the properly packaged library
> and the command line tools from being part of the stable release.

That may be worth considering post-jessie, but an unavoidable issue
right now is that ffmpeg arrived too late to make it into this release
cycle.

Best wishes,
Mike

Message #74 received at 763148@bugs.debian.org (full text, mbox, reply):

Hi,

On 05.10.2014 03:26, Michael Gilbert wrote:
> On Fri, Oct 3, 2014 at 1:44 PM, Andreas Cadhalpun wrote:
>> But I don't think that the mere possibility of such problems is a sufficient
>> reason to disregard Debian policy, which clearly states that embedded code
>> copies should not be used.
>> This is especially the case, if it prevents the properly packaged library
>> and the command line tools from being part of the stable release.
>
> That may be worth considering post-jessie, but an unavoidable issue
> right now is that ffmpeg arrived too late to make it into this release
> cycle.

Sorry, I don't understand what you're saying here:
The whole discussion we are having currently is about letting FFmpeg 
migrate to jessie!

So this is no 'unavoidable issue'.

But as you seem to be willing to consider this in principle, I think now 
the time has come for the release team to make an official decision:

Is FFmpeg allowed to migrate to testing, so that chromium can use it?

Or is chromium allowed to continue to use it's embedded copy?

Best regards,
Andreas

Acknowledgement sent to Emilio Pozuelo Monfort <pochu@debian.org>:
Extra info received and forwarded to list. Copy sent to Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>. (Sun, 05 Oct 2014 19:30:05 GMT) (full text, mbox, link).

Message #79 received at 763148@bugs.debian.org (full text, mbox, reply):

On 05/10/14 21:17, Andreas Cadhalpun wrote:
> Hi,
>
> On 05.10.2014 03:26, Michael Gilbert wrote:
>> On Fri, Oct 3, 2014 at 1:44 PM, Andreas Cadhalpun wrote:
>>> But I don't think that the mere possibility of such problems is a sufficient
>>> reason to disregard Debian policy, which clearly states that embedded code
>>> copies should not be used.
>>> This is especially the case, if it prevents the properly packaged library
>>> and the command line tools from being part of the stable release.
>>
>> That may be worth considering post-jessie, but an unavoidable issue
>> right now is that ffmpeg arrived too late to make it into this release
>> cycle.
>
> Sorry, I don't understand what you're saying here:
> The whole discussion we are having currently is about letting FFmpeg migrate to
> jessie!
>
> So this is no 'unavoidable issue'.
>
> But as you seem to be willing to consider this in principle, I think now the
> time has come for the release team to make an official decision:
>
> Is FFmpeg allowed to migrate to testing, so that chromium can use it?
>
> Or is chromium allowed to continue to use it's embedded copy?

We won't let ffmpeg into Jessie.

Ask again after Jessie is released.

And please stop asking the same question over and over again.

Emilio

Acknowledgement sent to Cyril Brulebois <kibi@debian.org>:
Extra info received and forwarded to list. Copy sent to Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>. (Sun, 05 Oct 2014 19:30:09 GMT) (full text, mbox, link).

Message #84 received at 763148@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Andreas Cadhalpun <andreas.cadhalpun@googlemail.com> (2014-10-05):
> The whole discussion we are having currently is about letting FFmpeg
> migrate to jessie!
> 
> So this is no 'unavoidable issue'.
> 
> But as you seem to be willing to consider this in principle, I think
> now the time has come for the release team to make an official
> decision:
> 
> Is FFmpeg allowed to migrate to testing, so that chromium can use it?
> 
> Or is chromium allowed to continue to use it's embedded copy?

I'm not sure why one would think the decision still needs to be made.

Mraw,
KiBi.

[signature.asc (application/pgp-signature, inline)]

Message #89 received at 763148@bugs.debian.org (full text, mbox, reply):

Hi,

On 05.10.2014 21:27, Cyril Brulebois wrote:
> Andreas Cadhalpun <andreas.cadhalpun@googlemail.com> (2014-10-05):
>> The whole discussion we are having currently is about letting FFmpeg
>> migrate to jessie!
>>
>> So this is no 'unavoidable issue'.
>>
>> But as you seem to be willing to consider this in principle, I think
>> now the time has come for the release team to make an official
>> decision:
>>
>> Is FFmpeg allowed to migrate to testing, so that chromium can use it?
>>
>> Or is chromium allowed to continue to use it's embedded copy?
>
> I'm not sure why one would think the decision still needs to be made.

That's because the last message from a release team member in this bug 
said [1]:
'However (and please note that I'm not a member of the security team
and just speak for myself here as always when not otherwise marked) if
it would be possible to replace the internal code copy in chromium
by a reference to ffmpeg (but it's not possible with libav), that will
probably lead to a re-evalutation. (That doesn't necessarily mean
"sucess guranteed", but it looks to me as it will not make things
worse.)'

It is possible to replace the internal code copy in chromium
by a reference to ffmpeg [2], so I thought this would lead to a 
re-evaluation.

Best regards,
Andreas

1: https://bugs.debian.org/763148#27
2: https://bugs.debian.org/763632

Message #94 received at 763148@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Andreas Cadhalpun <andreas.cadhalpun@googlemail.com> (2014-10-05):
> On 05.10.2014 21:27, Cyril Brulebois wrote:
> > I'm not sure why one would think the decision still needs to be made.
> 
> That's because the last message from a release team member in this
> bug said [1].

> 1: https://bugs.debian.org/763148#27

What I wrote applies to both Andreas.

Mraw,
KiBi.

[signature.asc (application/pgp-signature, inline)]

Message #99 received at 763148@bugs.debian.org (full text, mbox, reply):

Hi,

On 05.10.2014 22:38, Cyril Brulebois wrote:
> Andreas Cadhalpun <andreas.cadhalpun@googlemail.com> (2014-10-05):
>> On 05.10.2014 21:27, Cyril Brulebois wrote:
>>> I'm not sure why one would think the decision still needs to be made.
>>
>> That's because the last message from a release team member in this
>> bug said [1].
>
>> 1: https://bugs.debian.org/763148#27
>
> What I wrote applies to both Andreas.

When and how was this decision made, if apparently not even all release 
team members were aware of that?

Best regards,
Andreas

Message #104 received at 763148@bugs.debian.org (full text, mbox, reply):

* Andreas Cadhalpun (andreas.cadhalpun@googlemail.com) [141005 22:36]:
> That's because the last message from a release team member in this bug  
> said [1]:
> 'However (and please note that I'm not a member of the security team
> and just speak for myself here as always when not otherwise marked) if

As I said, I was just speaking for myself. That I might be at other
times speaking as a member of the release team doesn't make it an
opinion of the release team. For the release team opinion on this
topic seen Cyrils mails.

Also, the re-evaluation happened. It however didn't had the outcome
you wanted (basically because the web browser needs so many security
updates which only could be done by backporting all of it that the
embedded copy doesn't make any difference - this is an exceptional
thing which does happen but not very often. I can understand it, and
of course it's the call of the security team how to ensure that Debian
has security updates. I hadn't know that at the time I though about
the possibility, otherwise I would have already achived at that moment
at the conclusion).


Conclusion: Though I'm usually an optimistic person how to get things
achived, I don't see any way left how at this late time it's possible
to ship with ffmpeg in jessie. I'm sorry but we have to face the
facts. Independend if we like them or not (and I can fully understand
that you don't like them, but it's no good pretending facts are
different than they are). Sorry.


Andi

Acknowledgement sent to Raphael Geissert <geissert@debian.org>:
Extra info received and forwarded to list. Copy sent to Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>. (Sun, 05 Oct 2014 21:03:04 GMT) (full text, mbox, link).

Message #109 received at 763148@bugs.debian.org (full text, mbox, reply):

On Sunday 05 October 2014 22:48:17 Andreas Cadhalpun wrote:
> When and how was this decision made, if apparently not even all release
> team members were aware of that?

I refrained myself from making this comment on the previous debian-devel 
thread, but now I consider it necessary to be said: given your apparent lack 
of understanding of the situation and way of communicating it only makes me 
wonder on the ability to work with you as the maintainer of such a security-
sensitive package that ffmpeg is. I truly hope you understand the 
implications of such an impediment.

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

Message #114 received at 763148@bugs.debian.org (full text, mbox, reply):

Hi Raphael,

On 05.10.2014 23:01, Raphael Geissert wrote:
> I refrained myself from making this comment on the previous debian-devel
> thread, but now I consider it necessary to be said: given your apparent lack
> of understanding of the situation and way of communicating it only makes me
> wonder on the ability to work with you as the maintainer of such a security-
> sensitive package that ffmpeg is. I truly hope you understand the
> implications of such an impediment.

I always tried to understand the arguments of others and explain my 
point of view extensively.

I'm sorry if this wasn't how it looked to you.

Best regards,
Andreas

Message #119 received at 763148@bugs.debian.org (full text, mbox, reply):

Hi Andreas,

On 05.10.2014 22:54, Andreas Barth wrote:
> * Andreas Cadhalpun (andreas.cadhalpun@googlemail.com) [141005 22:36]:
>> That's because the last message from a release team member in this bug
>> said [1]:
>> 'However (and please note that I'm not a member of the security team
>> and just speak for myself here as always when not otherwise marked) if
>
> As I said, I was just speaking for myself. That I might be at other
> times speaking as a member of the release team doesn't make it an
> opinion of the release team. For the release team opinion on this
> topic seen Cyrils mails.
>
> Also, the re-evaluation happened. It however didn't had the outcome
> you wanted (basically because the web browser needs so many security
> updates which only could be done by backporting all of it that the
> embedded copy doesn't make any difference - this is an exceptional
> thing which does happen but not very often. I can understand it, and
> of course it's the call of the security team how to ensure that Debian
> has security updates. I hadn't know that at the time I though about
> the possibility, otherwise I would have already achived at that moment
> at the conclusion).
>
>
> Conclusion: Though I'm usually an optimistic person how to get things
> achived, I don't see any way left how at this late time it's possible
> to ship with ffmpeg in jessie. I'm sorry but we have to face the
> facts. Independend if we like them or not (and I can fully understand
> that you don't like them, but it's no good pretending facts are
> different than they are). Sorry.

Thanks for explaining.

It's sad that it isn't possible to have FFmpeg in jessie, but hopefully 
it'll be in jessie+1.

Best regards,
Andreas

Information forwarded to debian-bugs-dist@lists.debian.org, Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>:
Bug#763148; Package ffmpeg. (Mon, 06 Oct 2014 13:39:12 GMT) (full text, mbox, link).

Acknowledgement sent to "David L. Craig" <dlc.usa@gmail.com>:
Extra info received and forwarded to list. Copy sent to Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>. (Mon, 06 Oct 2014 13:39:12 GMT) (full text, mbox, link).

Message #124 received at 763148@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

On 14Oct05:2254+0200, Andreas Barth wrote:

> Also, the re-evaluation happened. It however didn't had the outcome
> you wanted (basically because the web browser needs so many security
> updates which only could be done by backporting all of it that the
> embedded copy doesn't make any difference - this is an exceptional
> thing which does happen but not very often. I can understand it, and
> of course it's the call of the security team how to ensure that Debian
> has security updates. I hadn't know that at the time I though about
> the possibility, otherwise I would have already achived at that moment
> at the conclusion).

Where are the minutes of the re-evaluation?
-- 
<not cent from sell>
May the LORD God bless you exceedingly abundantly!

Dave_Craig______________________________________________
"So the universe is not quite as you thought it was.
 You'd better rearrange your beliefs, then.
 Because you certainly can't rearrange the universe."
__--from_Nightfall_by_Asimov/Silverberg_________________

[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>:
Bug#763148; Package ffmpeg. (Sat, 18 Oct 2014 15:09:11 GMT) (full text, mbox, link).

Acknowledgement sent to Balint Reczey <balint@balintreczey.hu>:
Extra info received and forwarded to list. Copy sent to Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>. (Sat, 18 Oct 2014 15:09:11 GMT) (full text, mbox, link).

Message #129 received at 763148@bugs.debian.org (full text, mbox, reply):

Dear Security and Release Teams,

On Sun, 05 Oct 2014 23:23:07 +0200 Andreas Cadhalpun
<andreas.cadhalpun@googlemail.com> wrote:
> Hi Andreas,
> 
> On 05.10.2014 22:54, Andreas Barth wrote:
> > * Andreas Cadhalpun (andreas.cadhalpun@googlemail.com) [141005 22:36]:
> >> That's because the last message from a release team member in this bug
> >> said [1]:
> >> 'However (and please note that I'm not a member of the security team
> >> and just speak for myself here as always when not otherwise marked) if
> >
> > As I said, I was just speaking for myself. That I might be at other
> > times speaking as a member of the release team doesn't make it an
> > opinion of the release team. For the release team opinion on this
> > topic seen Cyrils mails.
> >
> > Also, the re-evaluation happened. It however didn't had the outcome
> > you wanted (basically because the web browser needs so many security
> > updates which only could be done by backporting all of it that the
> > embedded copy doesn't make any difference - this is an exceptional
> > thing which does happen but not very often. I can understand it, and
> > of course it's the call of the security team how to ensure that Debian
> > has security updates. I hadn't know that at the time I though about
> > the possibility, otherwise I would have already achived at that moment
> > at the conclusion).
> >
> >
> > Conclusion: Though I'm usually an optimistic person how to get things
> > achived, I don't see any way left how at this late time it's possible
> > to ship with ffmpeg in jessie. I'm sorry but we have to face the
> > facts. Independend if we like them or not (and I can fully understand
> > that you don't like them, but it's no good pretending facts are
> > different than they are). Sorry.
> 
> Thanks for explaining.
> 
> It's sad that it isn't possible to have FFmpeg in jessie, but hopefully 
> it'll be in jessie+1.
Could you please confirm that bug will be closed and FFmpeg will be let
migrating to testing after Jessie's release no matter if Libav is still
present there?
The current packaging of FFmpeg lets it to co-exist with Libav and the
next release cycle could be used to test it more extensively.

Cheers,
Balint

Acknowledgement sent to Moritz Muehlenhoff <jmm@inutil.org>:
Extra info received and forwarded to list. Copy sent to Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>. (Sat, 18 Oct 2014 16:18:05 GMT) (full text, mbox, link).

Message #134 received at 763148@bugs.debian.org (full text, mbox, reply):

On Sat, Oct 18, 2014 at 05:08:11PM +0200, Balint Reczey wrote:

> Could you please confirm that bug will be closed and FFmpeg will be let
> migrating to testing after Jessie's release no matter if Libav is still
> present there?

After the jessie release a decision between libav and ffmpeg will need
to be made. It certainly possible to have them co-exist for a year or
so, but the decision needs to be made before the jessie+1 freeze.

Cheers,
        Moritz

Information forwarded to debian-bugs-dist@lists.debian.org, Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>:
Bug#763148; Package ffmpeg. (Thu, 19 Feb 2015 01:21:05 GMT) (full text, mbox, link).

Acknowledgement sent to Paul Elliott <pelliott@blackpatchpanel.com>:
Extra info received and forwarded to list. Copy sent to Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>. (Thu, 19 Feb 2015 01:21:05 GMT) (full text, mbox, link).

Message #139 received at 763148@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Just to see what the fuss was about, and because I wanted
to use ffmpeg, I grabbed the unstable source and tried to
build with "sbuild -d testing".

I got an undefied dependancy on libx265-dev.

Sure enough I checked debian packages and libx265-dev
is in unstable but not testing.

I am testing, i386.


Could it be that ffmpeg is blocked for this other reason,
and the whole discussion on this bug is pointless?

Best Wishes to all.


-- 
Paul Elliott                               1(512)837-1096
pelliott@BlackPatchPanel.com               PMB 181, 11900 Metric Blvd Suite J
http://www.free.blackpatchpanel.com/pme/   Austin TX 78758-3117

[signature.asc (application/pgp-signature, inline)]

Acknowledgement sent to Timothy Gu <timothygu99@gmail.com>:
Extra info received and forwarded to list. Copy sent to Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>. (Thu, 19 Feb 2015 01:27:04 GMT) (full text, mbox, link).

Message #144 received at 763148@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Hi Paul,

It's more like the other way around. Because it is determined that ffmpeg
won't get into Jessie, we make no effort of making it work on Jessie.

You can however try cloning the source repo and manually disabling x265
support, and it should work (assuming all other dependencies are satisfied).

Timothy
On Wed, Feb 18, 2015 at 5:21 PM Paul Elliott <pelliott@blackpatchpanel.com>
wrote:

>
>
> Just to see what the fuss was about, and because I wanted
> to use ffmpeg, I grabbed the unstable source and tried to
> build with "sbuild -d testing".
>
> I got an undefied dependancy on libx265-dev.
>
> Sure enough I checked debian packages and libx265-dev
> is in unstable but not testing.
>
> I am testing, i386.
>
>
> Could it be that ffmpeg is blocked for this other reason,
> and the whole discussion on this bug is pointless?
>
> Best Wishes to all.
>
>
> --
> Paul Elliott                               1(512)837-1096
> pelliott@BlackPatchPanel.com               PMB 181, 11900 Metric Blvd
> Suite J
> http://www.free.blackpatchpanel.com/pme/   Austin TX 78758-3117
>

[Message part 2 (text/html, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>:
Bug#763148; Package ffmpeg. (Sat, 28 Feb 2015 16:54:04 GMT) (full text, mbox, link).

Acknowledgement sent to ciryat <i@ciry.at>:
Extra info received and forwarded to list. Copy sent to Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>. (Sat, 28 Feb 2015 16:54:04 GMT) (full text, mbox, link).

Message #149 received at 763148@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Andreas,

how about leaving all these package conflicts and quarrels (that already 
waste enough time of thousands of developers) behind and just use 
0install, which is a /distributed/ package management system (supporting 
all POSIX + Windows with one and only one package).

http://0install.net/0install-2.0.html
Or directly from git.
https://github.com/0install/0install

Or install 0install from the package repositories of (most) distros.

There are many examples on the webpage. As an example, see
https://github.com/ryppl/boost-zero

For common questions and answers of a dialogue with a package manager 
research group (Mancoosi), see:
http://thread.gmane.org/gmane.comp.file-systems.zero-install.devel/2322

Kind regards,
Jan

[Message part 2 (text/html, inline)]

Reply sent to Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>:
You have taken responsibility. (Sun, 26 Apr 2015 17:09:06 GMT) (full text, mbox, link).

Notification sent to Moritz Muehlenhoff <jmm@debian.org>:
Bug acknowledged by developer. (Sun, 26 Apr 2015 17:09:06 GMT) (full text, mbox, link).

Message #154 received at 763148-done@bugs.debian.org (full text, mbox, reply):

Dear release team,

as you undoubtedly know: jessie has been released! \o/

Thus this bug is now obsolete and I'm closing it.

Please remove the testing migration block of ffmpeg.

Best regards,
Andreas

Information forwarded to debian-bugs-dist@lists.debian.org, Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>:
Bug#763148; Package ffmpeg. (Sun, 26 Apr 2015 22:03:04 GMT) (full text, mbox, link).

Message #159 received at 763148@bugs.debian.org (full text, mbox, reply):

On 26/04/15 19:06, Andreas Cadhalpun wrote:
> Dear release team,
> 
> as you undoubtedly know: jessie has been released! \o/
> 
> Thus this bug is now obsolete and I'm closing it.
> 
> Please remove the testing migration block of ffmpeg.

I don't think you understand the problem.

Having both ffmpeg and libav in the same release is the problem. So at this
moment, that "block" hint is not going to be removed.

Emilio

Message #164 received at 763148@bugs.debian.org (full text, mbox, reply):

On 27.04.2015 00:01, Emilio Pozuelo Monfort wrote:
> On 26/04/15 19:06, Andreas Cadhalpun wrote:
>> Dear release team,
>>
>> as you undoubtedly know: jessie has been released! \o/
>>
>> Thus this bug is now obsolete and I'm closing it.
>>
>> Please remove the testing migration block of ffmpeg.
> 
> I don't think you understand the problem.
> 
> Having both ffmpeg and libav in the same release is the problem.

But having mysql-5.5 and mariadb-10.0 in jessie is apparently no
problem, despite previous claims. What's the difference?

> So at this moment, that "block" hint is not going to be removed.

When will it be removed, if not now?

Previously Moritz Mühlenhoff wrote [1]:
"After the jessie release a decision between libav and ffmpeg will need
to be made. It certainly possible to have them co-exist for a year or
so, but the decision needs to be made before the jessie+1 freeze."

How do you think this should go forward?

Best regards,
Andreas

1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763148#134

Added tag(s) stretch. Request was from Ivo De Decker <ivodd@debian.org> to control@bugs.debian.org. (Tue, 28 Apr 2015 17:18:36 GMT) (full text, mbox, link).

Removed tag(s) sid and stretch. Request was from Andreas Cadhalpun <andreas.cadhalpun@googlemail.com> to control@bugs.debian.org. (Tue, 28 Apr 2015 19:12:19 GMT) (full text, mbox, link).

Information forwarded to debian-bugs-dist@lists.debian.org, Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>:
Bug#763148; Package ffmpeg. (Wed, 29 Apr 2015 07:48:05 GMT) (full text, mbox, link).

Acknowledgement sent to Emilio Pozuelo Monfort <pochu@debian.org>:
Extra info received and forwarded to list. Copy sent to Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>. (Wed, 29 Apr 2015 07:48:05 GMT) (full text, mbox, link).

Message #173 received at 763148@bugs.debian.org (full text, mbox, reply):

On 27/04/15 00:30, Andreas Cadhalpun wrote:
> On 27.04.2015 00:01, Emilio Pozuelo Monfort wrote:
>> On 26/04/15 19:06, Andreas Cadhalpun wrote:
>>> Dear release team,
>>>
>>> as you undoubtedly know: jessie has been released! \o/
>>>
>>> Thus this bug is now obsolete and I'm closing it.
>>>
>>> Please remove the testing migration block of ffmpeg.
>>
>> I don't think you understand the problem.
>>
>> Having both ffmpeg and libav in the same release is the problem.
> 
> But having mysql-5.5 and mariadb-10.0 in jessie is apparently no
> problem, despite previous claims. What's the difference?
> 
>> So at this moment, that "block" hint is not going to be removed.
> 
> When will it be removed, if not now?
> 
> Previously Moritz Mühlenhoff wrote [1]:
> "After the jessie release a decision between libav and ffmpeg will need
> to be made. It certainly possible to have them co-exist for a year or
> so, but the decision needs to be made before the jessie+1 freeze."
> 
> How do you think this should go forward?

You could ask the TC to decide between the two. As it happened with #717076 for
example.

Emilio

Acknowledgement sent to balint@balintreczey.hu:
Extra info received and forwarded to list. Copy sent to Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>. (Wed, 29 Apr 2015 08:45:05 GMT) (full text, mbox, link).

Message #178 received at 763148@bugs.debian.org (full text, mbox, reply):

2015-04-29 9:44 GMT+02:00 Emilio Pozuelo Monfort <pochu@debian.org>:
> On 27/04/15 00:30, Andreas Cadhalpun wrote:
>> On 27.04.2015 00:01, Emilio Pozuelo Monfort wrote:
>>> On 26/04/15 19:06, Andreas Cadhalpun wrote:
>>>> Dear release team,
>>>>
>>>> as you undoubtedly know: jessie has been released! \o/
>>>>
>>>> Thus this bug is now obsolete and I'm closing it.
>>>>
>>>> Please remove the testing migration block of ffmpeg.
>>>
>>> I don't think you understand the problem.
>>>
>>> Having both ffmpeg and libav in the same release is the problem.
>>
>> But having mysql-5.5 and mariadb-10.0 in jessie is apparently no
>> problem, despite previous claims. What's the difference?
>>
>>> So at this moment, that "block" hint is not going to be removed.
>>
>> When will it be removed, if not now?
>>
>> Previously Moritz Mühlenhoff wrote [1]:
>> "After the jessie release a decision between libav and ffmpeg will need
>> to be made. It certainly possible to have them co-exist for a year or
>> so, but the decision needs to be made before the jessie+1 freeze."
>>
>> How do you think this should go forward?
>
> You could ask the TC to decide between the two. As it happened with #717076 for
> example.
There is no need to ask TC (yet), it is blocked by Julien:
https://release.debian.org/britney/hints/jcristau

Dear Julien,

Could you please lift the unblock now since Jessie has been released
and we generally don't ban packages from entering testing based on
duplicate functionality?

Thanks,
Balint

Acknowledgement sent to Emilio Pozuelo Monfort <pochu@debian.org>:
Extra info received and forwarded to list. Copy sent to Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>. (Wed, 29 Apr 2015 10:30:15 GMT) (full text, mbox, link).

Message #183 received at 763148@bugs.debian.org (full text, mbox, reply):

On 29/04/15 10:41, Bálint Réczey wrote:
> 2015-04-29 9:44 GMT+02:00 Emilio Pozuelo Monfort <pochu@debian.org>:
>> On 27/04/15 00:30, Andreas Cadhalpun wrote:
>>> On 27.04.2015 00:01, Emilio Pozuelo Monfort wrote:
>>>> On 26/04/15 19:06, Andreas Cadhalpun wrote:
>>>>> Dear release team,
>>>>>
>>>>> as you undoubtedly know: jessie has been released! \o/
>>>>>
>>>>> Thus this bug is now obsolete and I'm closing it.
>>>>>
>>>>> Please remove the testing migration block of ffmpeg.
>>>>
>>>> I don't think you understand the problem.
>>>>
>>>> Having both ffmpeg and libav in the same release is the problem.
>>>
>>> But having mysql-5.5 and mariadb-10.0 in jessie is apparently no
>>> problem, despite previous claims. What's the difference?
>>>
>>>> So at this moment, that "block" hint is not going to be removed.
>>>
>>> When will it be removed, if not now?
>>>
>>> Previously Moritz Mühlenhoff wrote [1]:
>>> "After the jessie release a decision between libav and ffmpeg will need
>>> to be made. It certainly possible to have them co-exist for a year or
>>> so, but the decision needs to be made before the jessie+1 freeze."
>>>
>>> How do you think this should go forward?
>>
>> You could ask the TC to decide between the two. As it happened with #717076 for
>> example.
> There is no need to ask TC (yet), it is blocked by Julien:
> https://release.debian.org/britney/hints/jcristau
> 
> Dear Julien,
> 
> Could you please lift the unblock now since Jessie has been released
> and we generally don't ban packages from entering testing based on
> duplicate functionality?

Sigh. This has been said multiple times, but I'll explain it again.

We do block stuff based on security concerns.

Since there are concerns on shipping both libav and ffmpeg, we won't allow
ffmpeg unless it is chosen to be the default and there is a clear transition
plan, so that we can switch from one to the other. Only then will the block hint
be removed.

Hope that is clear.

Cheers,
Emilio

Acknowledgement sent to Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>:
Extra info received and forwarded to list. Copy sent to Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>. (Wed, 29 Apr 2015 11:51:21 GMT) (full text, mbox, link).

Message #188 received at 763148@bugs.debian.org (full text, mbox, reply):

On 29.04.2015 12:28, Emilio Pozuelo Monfort wrote:
> On 29/04/15 10:41, Bálint Réczey wrote:
>> 2015-04-29 9:44 GMT+02:00 Emilio Pozuelo Monfort <pochu@debian.org>:
>>> On 27/04/15 00:30, Andreas Cadhalpun wrote:
>>>> On 27.04.2015 00:01, Emilio Pozuelo Monfort wrote:
>>>>> On 26/04/15 19:06, Andreas Cadhalpun wrote:
>>>>>> Dear release team,
>>>>>>
>>>>>> as you undoubtedly know: jessie has been released! \o/
>>>>>>
>>>>>> Thus this bug is now obsolete and I'm closing it.
>>>>>>
>>>>>> Please remove the testing migration block of ffmpeg.
>>>>>
>>>>> I don't think you understand the problem.
>>>>>
>>>>> Having both ffmpeg and libav in the same release is the problem.
>>>>
>>>> But having mysql-5.5 and mariadb-10.0 in jessie is apparently no
>>>> problem, despite previous claims. What's the difference?

It would really be nice to get an answer for this question.

>>>>> So at this moment, that "block" hint is not going to be removed.
>>>>
>>>> When will it be removed, if not now?
>>>>
>>>> Previously Moritz Mühlenhoff wrote [1]:
>>>> "After the jessie release a decision between libav and ffmpeg will need
>>>> to be made. It certainly possible to have them co-exist for a year or
>>>> so, but the decision needs to be made before the jessie+1 freeze."
>>>>
>>>> How do you think this should go forward?
>>>
>>> You could ask the TC to decide between the two. As it happened with #717076 for
>>> example.

The TC is only a last resort, used when the normal processes fail.
It would be much better if they would work.
Therefore I'm planning to discuss a possible transition from
Libav to FFmpeg with the maintainers of the reverse dependencies,
before asking the TC for a resolution.
However this will take time and I don't see any reason to block
ffmpeg from testing during this time.
It could be removed again before stretch is released, should that
prove necessary.

>> There is no need to ask TC (yet), it is blocked by Julien:
>> https://release.debian.org/britney/hints/jcristau
>>
>> Dear Julien,
>>
>> Could you please lift the unblock now since Jessie has been released
>> and we generally don't ban packages from entering testing based on
>> duplicate functionality?
> 
> Sigh. This has been said multiple times, but I'll explain it again.
> 
> We do block stuff based on security concerns.
> 
> Since there are concerns on shipping both libav and ffmpeg,

Just for your information: I'm currently in the process of finding and
fixing FFmpeg's remaining potentially security relevant bugs by systematically
fuzzing its demuxers/decoders with afl [1].
Once that's done (hopefully in the not too far future) security concerns
regarding FFmpeg should become more or less void.

And anyway, as far as I know, the only security support for testing comes
through unstable. So it's not like having FFmpeg in testing would increase
the workload of the security team.

> we won't allow
> ffmpeg unless it is chosen to be the default and there is a clear transition
> plan, so that we can switch from one to the other. Only then will the block hint
> be removed.
> 
> Hope that is clear.

Let me take your example of libjpeg-turbo: It has been in testing, when
the TC bug #717076 [2] was filed and during the year the decision was debated there,
except for a short time, were it was removed due to concrete unfixed security
issues [3].

It is not clear to me, why a similar treatment should not be possible for ffmpeg.

Best regards,
Andreas

1: https://tracker.debian.org/pkg/afl
   BTW: Thanks to Jakub Wilk for packaging afl!
2: https://bugs.debian.org/717076
3: https://bugs.debian.org/729873

Message #193 received at 763148@bugs.debian.org (full text, mbox, reply):

Dear Emilio,

2015-04-29 12:28 GMT+02:00 Emilio Pozuelo Monfort <pochu@debian.org>:
> On 29/04/15 10:41, Bálint Réczey wrote:
>> 2015-04-29 9:44 GMT+02:00 Emilio Pozuelo Monfort <pochu@debian.org>:
>>> On 27/04/15 00:30, Andreas Cadhalpun wrote:
>>>> On 27.04.2015 00:01, Emilio Pozuelo Monfort wrote:
>>>>> On 26/04/15 19:06, Andreas Cadhalpun wrote:
>>>>>> Dear release team,
>>>>>>
>>>>>> as you undoubtedly know: jessie has been released! \o/
>>>>>>
>>>>>> Thus this bug is now obsolete and I'm closing it.
>>>>>>
>>>>>> Please remove the testing migration block of ffmpeg.
>>>>>
>>>>> I don't think you understand the problem.
>>>>>
>>>>> Having both ffmpeg and libav in the same release is the problem.
>>>>
>>>> But having mysql-5.5 and mariadb-10.0 in jessie is apparently no
>>>> problem, despite previous claims. What's the difference?
>>>>
>>>>> So at this moment, that "block" hint is not going to be removed.
>>>>
>>>> When will it be removed, if not now?
>>>>
>>>> Previously Moritz Mühlenhoff wrote [1]:
>>>> "After the jessie release a decision between libav and ffmpeg will need
>>>> to be made. It certainly possible to have them co-exist for a year or
>>>> so, but the decision needs to be made before the jessie+1 freeze."
>>>>
>>>> How do you think this should go forward?
>>>
>>> You could ask the TC to decide between the two. As it happened with #717076 for
>>> example.
>> There is no need to ask TC (yet), it is blocked by Julien:
>> https://release.debian.org/britney/hints/jcristau
>>
>> Dear Julien,
>>
>> Could you please lift the unblock now since Jessie has been released
>> and we generally don't ban packages from entering testing based on
>> duplicate functionality?
>
> Sigh. This has been said multiple times, but I'll explain it again.
>
> We do block stuff based on security concerns.
I have just checked and you are not a member of the Security Team:
https://www.debian.org/intro/organization

The last word from the Security Team was Moritz's email which gave
ffmpeg green light after Jessie's release.

Please clarify if the opinion you shared here is your own private
opinion (as a DD) or the Release Team's official position.
Note that as a DD you can engage in discussions about ffmpeg but can't
keep the block alive.

>
> Since there are concerns on shipping both libav and ffmpeg, we won't allow
> ffmpeg unless it is chosen to be the default and there is a clear transition
> plan, so that we can switch from one to the other. Only then will the block hint
> be removed.
There are no technical reasons for not having both in testing an I see
this the only fair solution. There are no name- nor symbol collision
between the packages. They co-exist perfectly on my systems, too.

>
> Hope that is clear.
Your opinion is clear but I think you having this opinion should not
be enough to prevent the migration to testing and it would save a lot
of unnecessary debate if you could just let it go and see what
happens.

Cheers,
Balint

Acknowledgement sent to Alessandro Ghedini <ghedo@debian.org>:
Extra info received and forwarded to list. Copy sent to Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>. (Wed, 29 Apr 2015 13:03:10 GMT) (full text, mbox, link).

Message #198 received at 763148@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

On mer, apr 29, 2015 at 02:29:43 +0200, Bálint Réczey wrote:
> > Since there are concerns on shipping both libav and ffmpeg, we won't allow
> > ffmpeg unless it is chosen to be the default and there is a clear transition
> > plan, so that we can switch from one to the other. Only then will the block hint
> > be removed.
> There are no technical reasons for not having both in testing an I see
> this the only fair solution. There are no name- nor symbol collision
> between the packages. They co-exist perfectly on my systems, too.

There is at least one reason that I can think of. Assuming the decision to keep
either libav or ffmpeg (not both) stands, if ffmpeg is allowed to migrate and
other packages start depending on it, and if before the stretch release ffmpeg
is deemed not release ready (e.g. if libav is chosen), then more work will be
required to untangle the dependencies and have ffmpeg removed from testing.

Cheers

[signature.asc (application/pgp-signature, inline)]

Acknowledgement sent to Alessio Treglia <alessio@debian.org>:
Extra info received and forwarded to list. Copy sent to Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>. (Wed, 29 Apr 2015 13:30:09 GMT) (full text, mbox, link).

Message #203 received at 763148@bugs.debian.org (full text, mbox, reply):

On Wed, Apr 29, 2015 at 12:47 PM, Andreas Cadhalpun
<andreas.cadhalpun@googlemail.com> wrote:
> Therefore I'm planning to discuss a possible transition from
> Libav to FFmpeg with the maintainers of the reverse dependencies,
> before asking the TC for a resolution.

What if one or more maintainers do not agree with you to make his
packages break away from libav? What result are you aiming to achieve?
Splitting multimedia packages up in two groups, each one depending on
a different implementation of the same interfaces? And on the basis of
what?

I feel that we'd better *first* decide on which one between ffmpeg and
libav we want to keep, and drop the alternative.

Cheers.

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

Acknowledgement sent to Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>:
Extra info received and forwarded to list. Copy sent to Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>. (Wed, 29 Apr 2015 13:30:13 GMT) (full text, mbox, link).

Message #208 received at 763148@bugs.debian.org (full text, mbox, reply):

Hi Alessandro,

On 29.04.2015 14:58, Alessandro Ghedini wrote:
> On mer, apr 29, 2015 at 02:29:43 +0200, Bálint Réczey wrote:
>>> Since there are concerns on shipping both libav and ffmpeg, we won't allow
>>> ffmpeg unless it is chosen to be the default and there is a clear transition
>>> plan, so that we can switch from one to the other. Only then will the block hint
>>> be removed.
>> There are no technical reasons for not having both in testing an I see
>> this the only fair solution. There are no name- nor symbol collision
>> between the packages. They co-exist perfectly on my systems, too.
> 
> There is at least one reason that I can think of. Assuming the decision to keep
> either libav or ffmpeg (not both) stands,

Great to hear that this is only an assumption and no definitive statement!

> if ffmpeg is allowed to migrate and
> other packages start depending on it,

Packages already depend on FFmpeg, simply because they don't work with Libav:
pencil2d, vokoscreen, kodi (in NEW [1]), chromium (using embedded copy),
mplayer (ITP: #763826 [2])

> and if before the stretch release ffmpeg
> is deemed not release ready (e.g. if libav is chosen), then more work will be
> required to untangle the dependencies and have ffmpeg removed from testing.

If a preliminary decision is made in e.g. one years time, maintainers would have
plenty of time to adapt.

And if FFmpeg is not allowed into testing, this will mean more work for those
wanting/needing to use it, like e.g. adding patches to not fail completely,
when using Libav.
If the final decision would be to only allow FFmpeg, not having had it in
testing would also mean, well, less testing, of itself and possibly reverse-dependencies
using it instead of Libav. (Currently most don't provide versions compiled
against both. Thanks for doing this with mpv, by the way.)
It would also be difficult to get testing for a fix of #763632 [3], as long
as FFmpeg is not in testing.

So there is work involved both ways.

Best regards,
Andreas

1: https://ftp-master.debian.org/new/kodi_14.2+dfsg1-1.html
2: https://bugs.debian.org/763826
3: https://bugs.debian.org/763632

Message #213 received at 763148@bugs.debian.org (full text, mbox, reply):

Hi Alessandro,

2015-04-29 14:58 GMT+02:00 Alessandro Ghedini <ghedo@debian.org>:
> On mer, apr 29, 2015 at 02:29:43 +0200, Bálint Réczey wrote:
>> > Since there are concerns on shipping both libav and ffmpeg, we won't allow
>> > ffmpeg unless it is chosen to be the default and there is a clear transition
>> > plan, so that we can switch from one to the other. Only then will the block hint
>> > be removed.
>> There are no technical reasons for not having both in testing an I see
>> this the only fair solution. There are no name- nor symbol collision
>> between the packages. They co-exist perfectly on my systems, too.
>
> There is at least one reason that I can think of. Assuming the decision to keep
> either libav or ffmpeg (not both) stands, if ffmpeg is allowed to migrate and
> other packages start depending on it, and if before the stretch release ffmpeg
> is deemed not release ready (e.g. if libav is chosen), then more work will be
> required to untangle the dependencies and have ffmpeg removed from testing.
We can start the migration one year before the freeze date if only one
of libav/ffmpeg is to be kept in Stretch.
IMO we can keep both. I watched FFmpeg closely and the are very fast
in fixing security issues and in general handling of bugs. OTOH I also
think Libav deserves to be in testing/stable if they can fix their
issues in a timely manner.
If we want to assess the effort of supporting both or either of them
we can count the number of hours spent supporting each on release
management/security support/reverse depenencies' maintainer work.
I spent way more than 80 hours on XBMC/Kodi because of the absence of
FFmpeg in Debian for example.

Cheers,
Balint

Acknowledgement sent to Emilio Pozuelo Monfort <pochu@debian.org>:
Extra info received and forwarded to list. Copy sent to Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>. (Wed, 29 Apr 2015 13:42:05 GMT) (full text, mbox, link).

Message #218 received at 763148@bugs.debian.org (full text, mbox, reply):

On 29/04/15 14:29, Bálint Réczey wrote:
> The last word from the Security Team was Moritz's email which gave
> ffmpeg green light after Jessie's release.

No. He said that a decision between libav and ffmpeg would still have to be
made. IOW, we won't ship Stretch with both libav and ffmpeg.

Allowing ffmpeg to migrate now and have half of the rdeps switch from libav to
ffmpeg is only going to make things worse when we have to pull one of the two
with all its rdeps from testing one month before the freeze.

What is your plan to avoid that?

Emilio

Message #223 received at 763148@bugs.debian.org (full text, mbox, reply):

2015-04-29 15:38 GMT+02:00 Emilio Pozuelo Monfort <pochu@debian.org>:
> On 29/04/15 14:29, Bálint Réczey wrote:
>> The last word from the Security Team was Moritz's email which gave
>> ffmpeg green light after Jessie's release.
>
> No. He said that a decision between libav and ffmpeg would still have to be
> made. IOW, we won't ship Stretch with both libav and ffmpeg.
He gave a green light to migration, it is very clear.
Please answer my question, I'm not sure who I am talking to:
>> Please clarify if the opinion you shared here is your own private
>> opinion (as a DD) or the Release Team's official position.
>> Note that as a DD you can engage in discussions about ffmpeg but can't
>> keep the block alive.

Balint

Message #228 received at 763148@bugs.debian.org (full text, mbox, reply):

On Wed, Apr 29, 2015 at 2:46 PM, Bálint Réczey <balint@balintreczey.hu> wrote:
> He gave a green light to migration, it is very clear.

If you're thinking of this [1] then yes, it's very clear that is *NOT*
a green light at all.


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763148#134

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

Message #233 received at 763148@bugs.debian.org (full text, mbox, reply):

2015-04-29 15:27 GMT+02:00 Alessio Treglia <alessio@debian.org>:
> On Wed, Apr 29, 2015 at 12:47 PM, Andreas Cadhalpun
> <andreas.cadhalpun@googlemail.com> wrote:
>> Therefore I'm planning to discuss a possible transition from
>> Libav to FFmpeg with the maintainers of the reverse dependencies,
>> before asking the TC for a resolution.
>
> What if one or more maintainers do not agree with you to make his
> packages break away from libav? What result are you aiming to achieve?
> Splitting multimedia packages up in two groups, each one depending on
> a different implementation of the same interfaces? And on the basis of
> what?
Libav and ffmpeg provide different interfaces and different
implementation in ffmpeg's current packaging solution.
Having packages depending on alternative implementations is business
as usual and upstreams have different preferences. Usually maintainers
are free to choose any other package as dependency whichever they find
the best fit for their package and IMO it is a good practice. This bug
is not about removing Libav this bug is about handling ffmpeg fairly
and letting it migrate to testing at least for a year.

>
> I feel that we'd better *first* decide on which one between ffmpeg and
> libav we want to keep, and drop the alternative.
I think you have the wrong feeling. Please consider the costs and
benefits instead of feelings. We can have both in even stable. The
cost of Libav + FFmpeg is slightly more than Libav only, while
upstreams and users are screaming for FFmpeg.

Cheers,
Balint

Message #238 received at 763148@bugs.debian.org (full text, mbox, reply):

Dear Moritz,

Could you please clarify Security Team's position? Do the Security
Team still want to keep ffmpeg out of testing?

Cheers,
Balint

2015-04-29 15:55 GMT+02:00 Alessio Treglia <alessio@debian.org>:
> On Wed, Apr 29, 2015 at 2:46 PM, Bálint Réczey <balint@balintreczey.hu> wrote:
>> He gave a green light to migration, it is very clear.
>
> If you're thinking of this [1] then yes, it's very clear that is *NOT*
> a green light at all.
>
>
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763148#134
>
> --
> Alessio Treglia          | www.alessiotreglia.com
> Debian Developer         |     alessio@debian.org
> Ubuntu Core Developer    |  quadrispro@ubuntu.com
> 0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A
>

Message #243 received at 763148@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

On Wed, Apr 29, 2015 at 03:28:40PM +0200, Andreas Cadhalpun wrote:
> Hi Alessandro,
> 
> On 29.04.2015 14:58, Alessandro Ghedini wrote:
> > On mer, apr 29, 2015 at 02:29:43 +0200, Bálint Réczey wrote:
> >>> Since there are concerns on shipping both libav and ffmpeg, we won't allow
> >>> ffmpeg unless it is chosen to be the default and there is a clear transition
> >>> plan, so that we can switch from one to the other. Only then will the block hint
> >>> be removed.
> >> There are no technical reasons for not having both in testing an I see
> >> this the only fair solution. There are no name- nor symbol collision
> >> between the packages. They co-exist perfectly on my systems, too.
> > 
> > There is at least one reason that I can think of. Assuming the decision to keep
> > either libav or ffmpeg (not both) stands,
> 
> Great to hear that this is only an assumption and no definitive statement!
> 
> > if ffmpeg is allowed to migrate and
> > other packages start depending on it,
> 
> Packages already depend on FFmpeg, simply because they don't work with Libav:

Yes, but they won't migrate to testing either.

> > and if before the stretch release ffmpeg
> > is deemed not release ready (e.g. if libav is chosen), then more work will be
> > required to untangle the dependencies and have ffmpeg removed from testing.
> 
> If a preliminary decision is made in e.g. one years time, maintainers would have
> plenty of time to adapt.

The decision has to be taken *now*, not in one year.

Last year, just before the freeze, we (the multimedia team) sort of held a vote
to decide this, but it went in favour of libav. IIRC the reason people voted in
favour of libav was that we were too close to the freeze to do anything.

Now would be the time to start that discussion again. So, instead of wasting
energies arguing against the migration block, I suggest you be the one to
restart that discussion, given that you are the maintainer of ffmpeg.

Cheers

[signature.asc (application/pgp-signature, inline)]

Acknowledgement sent to Timothy Gu <timothygu99@gmail.com>:
Extra info received and forwarded to list. Copy sent to Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>. (Wed, 29 Apr 2015 14:12:08 GMT) (full text, mbox, link).

Message #248 received at 763148@bugs.debian.org (full text, mbox, reply):

On Wed, Apr 29, 2015 at 02:55:39PM +0100, Alessio Treglia wrote:
> On Wed, Apr 29, 2015 at 2:46 PM, Bálint Réczey <balint@balintreczey.hu> wrote:
> > He gave a green light to migration, it is very clear.
> 
> If you're thinking of this [1] then yes, it's very clear that is *NOT*
> a green light at all.

I believe you are misunderstanding the email. It is very clear to me that
Moritz said two things:

1. FFmpeg and Libav can coexist for "a year or so"
2. A decision must be made before the Stretch freeze

#1 did not make it clear where the packages are coexisting, that is very
true. But for #2, the sentence would not have made any sense if the two
packages are not already in testing, as the freeze wouldn't matter if
ffmpeg is only in sid. As a result, it is fair to assume Moritz implied that 
a migration to testing, albeit temporary, is okay in the mean time.

Plus, just as Andreas said, what about mysql and mariadb? Why do those get
special treatment but ffmpeg/libav don't?

Timothy

Message #253 received at 763148@bugs.debian.org (full text, mbox, reply):

2015-04-29 16:08 GMT+02:00 Alessandro Ghedini <ghedo@debian.org>:
> On Wed, Apr 29, 2015 at 03:28:40PM +0200, Andreas Cadhalpun wrote:
>> Hi Alessandro,
>>
>> On 29.04.2015 14:58, Alessandro Ghedini wrote:
>> > On mer, apr 29, 2015 at 02:29:43 +0200, Bálint Réczey wrote:
>> >>> Since there are concerns on shipping both libav and ffmpeg, we won't allow
>> >>> ffmpeg unless it is chosen to be the default and there is a clear transition
>> >>> plan, so that we can switch from one to the other. Only then will the block hint
>> >>> be removed.
>> >> There are no technical reasons for not having both in testing an I see
>> >> this the only fair solution. There are no name- nor symbol collision
>> >> between the packages. They co-exist perfectly on my systems, too.
>> >
>> > There is at least one reason that I can think of. Assuming the decision to keep
>> > either libav or ffmpeg (not both) stands,
>>
>> Great to hear that this is only an assumption and no definitive statement!
>>
>> > if ffmpeg is allowed to migrate and
>> > other packages start depending on it,
>>
>> Packages already depend on FFmpeg, simply because they don't work with Libav:
>
> Yes, but they won't migrate to testing either.
>
>> > and if before the stretch release ffmpeg
>> > is deemed not release ready (e.g. if libav is chosen), then more work will be
>> > required to untangle the dependencies and have ffmpeg removed from testing.
>>
>> If a preliminary decision is made in e.g. one years time, maintainers would have
>> plenty of time to adapt.
>
> The decision has to be taken *now*, not in one year.
Nope. It is just your opinion. IMO this decision is not needed at all.

>
> Last year, just before the freeze, we (the multimedia team) sort of held a vote
> to decide this, but it went in favour of libav. IIRC the reason people voted in
> favour of libav was that we were too close to the freeze to do anything.
>
> Now would be the time to start that discussion again. So, instead of wasting
> energies arguing against the migration block, I suggest you be the one to
> restart that discussion, given that you are the maintainer of ffmpeg.
Just lift the block and it will end the the argument.
Asking Multimedia Team is wrong way is making the call. It is
_pretending_ to be cooperative.
Why don't you ask KDE maintainers if they want to see GNOME in the archive?

Cheers,
Balint

Message #258 received at 763148@bugs.debian.org (full text, mbox, reply):

2015-04-29 16:17 GMT+02:00 Bálint Réczey <balint@balintreczey.hu>:
> 2015-04-29 16:08 GMT+02:00 Alessandro Ghedini <ghedo@debian.org>:
>> On Wed, Apr 29, 2015 at 03:28:40PM +0200, Andreas Cadhalpun wrote:
>>> Hi Alessandro,
>>>
>>> On 29.04.2015 14:58, Alessandro Ghedini wrote:
>>> > On mer, apr 29, 2015 at 02:29:43 +0200, Bálint Réczey wrote:
>>> >>> Since there are concerns on shipping both libav and ffmpeg, we won't allow
>>> >>> ffmpeg unless it is chosen to be the default and there is a clear transition
>>> >>> plan, so that we can switch from one to the other. Only then will the block hint
>>> >>> be removed.
>>> >> There are no technical reasons for not having both in testing an I see
>>> >> this the only fair solution. There are no name- nor symbol collision
>>> >> between the packages. They co-exist perfectly on my systems, too.
>>> >
>>> > There is at least one reason that I can think of. Assuming the decision to keep
>>> > either libav or ffmpeg (not both) stands,
>>>
>>> Great to hear that this is only an assumption and no definitive statement!
>>>
>>> > if ffmpeg is allowed to migrate and
>>> > other packages start depending on it,
>>>
>>> Packages already depend on FFmpeg, simply because they don't work with Libav:
>>
>> Yes, but they won't migrate to testing either.
>>
>>> > and if before the stretch release ffmpeg
>>> > is deemed not release ready (e.g. if libav is chosen), then more work will be
>>> > required to untangle the dependencies and have ffmpeg removed from testing.
>>>
>>> If a preliminary decision is made in e.g. one years time, maintainers would have
>>> plenty of time to adapt.
>>
>> The decision has to be taken *now*, not in one year.
> Nope. It is just your opinion. IMO this decision is not needed at all.
Or if this is Security Team's official opinion then please signal that.

Cheers,
Balint

Message #263 received at 763148@bugs.debian.org (full text, mbox, reply):

On Wed, Apr 29, 2015 at 3:09 PM, Timothy Gu <timothygu99@gmail.com> wrote:
> 1. FFmpeg and Libav can coexist for "a year or so"
> 2. A decision must be made before the Stretch freeze
> #1 did not make it clear where the packages are coexisting, that is very
> true. But for #2, the sentence would not have made any sense if the two
> packages are not already in testing, as the freeze wouldn't matter if
> ffmpeg is only in sid. As a result, it is fair to assume Moritz implied that
> a migration to testing, albeit temporary, is okay in the mean time.

Neither 1. nor 2. appears like a bloody green light to me.
You are "assuming that someone implied" something, that is quite
different to "he gave a green light to migration, it is very clear".

On Wed, Apr 29, 2015 at 3:17 PM, Bálint Réczey <balint@balintreczey.hu> wrote:
> Asking Multimedia Team is wrong way is making the call. It is
> _pretending_ to be cooperative.

I remember only constructive conversations about this topic in DMM
team's mailing list.
Please do elaborate, this is not fair at all.

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

Acknowledgement sent to Jonathan Wiltshire <jmw@debian.org>:
Extra info received and forwarded to list. Copy sent to Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>. (Wed, 29 Apr 2015 14:54:13 GMT) (full text, mbox, link).

Message #268 received at 763148@bugs.debian.org (full text, mbox, reply):

On 2015-04-29 12:47, Andreas Cadhalpun wrote:
> On 29.04.2015 12:28, Emilio Pozuelo Monfort wrote:
>> On 29/04/15 10:41, Bálint Réczey wrote:
>>> 2015-04-29 9:44 GMT+02:00 Emilio Pozuelo Monfort <pochu@debian.org>:
>>>> On 27/04/15 00:30, Andreas Cadhalpun wrote:
>>>>> On 27.04.2015 00:01, Emilio Pozuelo Monfort wrote:
>>>>>> On 26/04/15 19:06, Andreas Cadhalpun wrote:
>>>>>>> Dear release team,
>>>>>>> 
>>>>>>> as you undoubtedly know: jessie has been released! \o/
>>>>>>> 
>>>>>>> Thus this bug is now obsolete and I'm closing it.
>>>>>>> 
>>>>>>> Please remove the testing migration block of ffmpeg.
>>>>>> 
>>>>>> I don't think you understand the problem.
>>>>>> 
>>>>>> Having both ffmpeg and libav in the same release is the problem.
>>>>> 
>>>>> But having mysql-5.5 and mariadb-10.0 in jessie is apparently no
>>>>> problem, despite previous claims. What's the difference?
> 
> It would really be nice to get an answer for this question.

mysql-5.5 and mariadb-10.0 in Jessie is not exactly "no problem". There 
were extensive discussions before the freeze about which of the *four* 
forks of MySQL would ship in Jessie.

Bear in mind that MySQL and Maria were both already in testing at this 
point. The security team understandably want to support only one fork. 
The maintainers could not agree which it should be.

We eventually arranged to ship two of those four forks in Jessie with a 
view to having only one in Stretch,  easing the transition for users if 
it ends up being Maria. That aim has not changed. Jessie was a 
compromise situation.

This isn't a good direct comparison with ffmpeg/libav since we do not 
have the situation of them both in testing at the moment, and I believe 
that should remain the case until one or the other becomes the obvious 
candidate. We do not want to end up with dependencies on both in testing 
that need to be untangled later.

-- 
Jonathan Wiltshire                                      jmw@debian.org
Debian Developer                         http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

<directhex> i have six years of solaris sysadmin experience, from
            8->10. i am well qualified to say it is made from bonghits
			layered on top of bonghits

Information stored :
Bug#763148; Package ffmpeg. (Wed, 29 Apr 2015 15:42:05 GMT) (full text, mbox, link).

Acknowledgement sent to Jonathan Wiltshire <jmw@debian.org>:
Extra info received and filed, but not forwarded. (Wed, 29 Apr 2015 15:42:05 GMT) (full text, mbox, link).

Message #273 received at 763148-quiet@bugs.debian.org (full text, mbox, reply):

(re-sending for the benefit of -release)

On 2015-04-29 12:47, Andreas Cadhalpun wrote:
> On 29.04.2015 12:28, Emilio Pozuelo Monfort wrote:
>> On 29/04/15 10:41, Bálint Réczey wrote:
>>> 2015-04-29 9:44 GMT+02:00 Emilio Pozuelo Monfort <pochu@debian.org>:
>>>> On 27/04/15 00:30, Andreas Cadhalpun wrote:
>>>>> On 27.04.2015 00:01, Emilio Pozuelo Monfort wrote:
>>>>>> On 26/04/15 19:06, Andreas Cadhalpun wrote:
>>>>>>> Dear release team,
>>>>>>> 
>>>>>>> as you undoubtedly know: jessie has been released! \o/
>>>>>>> 
>>>>>>> Thus this bug is now obsolete and I'm closing it.
>>>>>>> 
>>>>>>> Please remove the testing migration block of ffmpeg.
>>>>>> 
>>>>>> I don't think you understand the problem.
>>>>>> 
>>>>>> Having both ffmpeg and libav in the same release is the problem.
>>>>> 
>>>>> But having mysql-5.5 and mariadb-10.0 in jessie is apparently no
>>>>> problem, despite previous claims. What's the difference?
> 
> It would really be nice to get an answer for this question.

mysql-5.5 and mariadb-10.0 in Jessie is not exactly "no problem". There 
were extensive discussions before the freeze about which of the *four* 
forks of MySQL would ship in Jessie.

Bear in mind that MySQL and Maria were both already in testing at this 
point. The security team understandably want to support only one fork. 
The maintainers could not agree which it should be.

We eventually arranged to ship two of those four forks in Jessie with a 
view to having only one in Stretch,  easing the transition for users if 
it ends up being Maria. That aim has not changed. Jessie was a 
compromise situation.

This isn't a good direct comparison with ffmpeg/libav since we do not 
have the situation of them both in testing at the moment, and I believe 
that should remain the case until one or the other becomes the obvious 
candidate. We do not want to end up with dependencies on both in testing 
that need to be untangled later.

-- 
Jonathan Wiltshire                                      jmw@debian.org
Debian Developer                         http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

<directhex> i have six years of solaris sysadmin experience, from
            8->10. i am well qualified to say it is made from bonghits
		layered on top of bonghits

Acknowledgement sent to Joerg Jaspert <joerg@debian.org>:
Extra info received and forwarded to list. Copy sent to Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>. (Wed, 29 Apr 2015 16:24:05 GMT) (full text, mbox, link).

Message #278 received at 763148@bugs.debian.org (full text, mbox, reply):

On 13926 March 1977, Bálint Réczey wrote:
> 2015-04-29 15:38 GMT+02:00 Emilio Pozuelo Monfort <pochu@debian.org>:
>> On 29/04/15 14:29, Bálint Réczey wrote:
>>> The last word from the Security Team was Moritz's email which gave
>>> ffmpeg green light after Jessie's release.
>> No. He said that a decision between libav and ffmpeg would still have to be
>> made. IOW, we won't ship Stretch with both libav and ffmpeg.
> He gave a green light to migration, it is very clear.
> Please answer my question, I'm not sure who I am talking to:
>>> Please clarify if the opinion you shared here is your own private
>>> opinion (as a DD) or the Release Team's official position.
>>> Note that as a DD you can engage in discussions about ffmpeg but can't
>>> keep the block alive.

Reading this thread and how release team members get hit to allow one
package into testing makes me want to use my ftpmaster hat to remove it
entirely from Debian. Have you read their delegation? It's the release
teams right to keep a package out of testing, even if you don't like
them using that right.
And that goes for every single member, so sod the "your own private
opinion or teams position", as soon as someone tells you "no", then its
a no.

As usual with people using their delegated rights you have ways to go
get to change that. Tons of repeating on a list thread/bug is not one of
them. Especially not as you got told how it can get unblocked.

-- 
bye, Joerg

Message #283 received at 763148@bugs.debian.org (full text, mbox, reply):

Hi Joerg,

2015-04-29 18:12 GMT+02:00 Joerg Jaspert <joerg@debian.org>:
> On 13926 March 1977, Bálint Réczey wrote:
>> 2015-04-29 15:38 GMT+02:00 Emilio Pozuelo Monfort <pochu@debian.org>:
>>> On 29/04/15 14:29, Bálint Réczey wrote:
>>>> The last word from the Security Team was Moritz's email which gave
>>>> ffmpeg green light after Jessie's release.
>>> No. He said that a decision between libav and ffmpeg would still have to be
>>> made. IOW, we won't ship Stretch with both libav and ffmpeg.
>> He gave a green light to migration, it is very clear.
>> Please answer my question, I'm not sure who I am talking to:
>>>> Please clarify if the opinion you shared here is your own private
>>>> opinion (as a DD) or the Release Team's official position.
>>>> Note that as a DD you can engage in discussions about ffmpeg but can't
>>>> keep the block alive.
>
> Reading this thread and how release team members get hit to allow one
> package into testing makes me want to use my ftpmaster hat to remove it
> entirely from Debian. Have you read their delegation? It's the release
Thank you for not removing the package just because there are too many
discussions involving it. I appreciate your patience while I don't
share your feelings.

> teams right to keep a package out of testing, even if you don't like
> them using that right.
> And that goes for every single member, so sod the "your own private
> opinion or teams position", as soon as someone tells you "no", then its
> a no.
>
> As usual with people using their delegated rights you have ways to go
> get to change that. Tons of repeating on a list thread/bug is not one of
> them. Especially not as you got told how it can get unblocked.
IMO mandating the choice between the two libraries lacks technical
merit and is not fair to one or the other package maintainer/upstream.
I understand that we have limited resources but if the teams would
quantify the amount of workforce needed to support both libraries
vulunteers may apply to help them out.

Thanks,
Balint

Acknowledgement sent to Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>:
Extra info received and forwarded to list. Copy sent to Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>. (Wed, 29 Apr 2015 17:48:10 GMT) (full text, mbox, link).

Message #288 received at 763148@bugs.debian.org (full text, mbox, reply):

Hi Alessandro,

On 29.04.2015 16:08, Alessandro Ghedini wrote:
> The decision has to be taken *now*, not in one year.

We should start discussing, sure, but I would be surprised if a decision
could be reached in a time frame short enough to qualify as 'now'.

> Last year, just before the freeze, we (the multimedia team) sort of held a vote
> to decide this, but it went in favour of libav. IIRC the reason people voted in
> favour of libav was that we were too close to the freeze to do anything.
> 
> Now would be the time to start that discussion again. So, instead of wasting
> energies arguing against the migration block, I suggest you be the one to
> restart that discussion, given that you are the maintainer of ffmpeg.

As I already wrote [1], I plan to start such a discussion. However I thought that
meanwhile FFmpeg would be allowed into testing, as this seemed what Moritz
suggested: Have both in testing for a year, while discussing further actions.
Therefore I did not expect that this would be controversial.

Best regards,
Andreas

1: https://bugs.debian.org/763148#188

Acknowledgement sent to Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>:
Extra info received and forwarded to list. Copy sent to Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>. (Wed, 29 Apr 2015 17:57:04 GMT) (full text, mbox, link).

Message #293 received at 763148@bugs.debian.org (full text, mbox, reply):

Hi Alessio,

On 29.04.2015 15:27, Alessio Treglia wrote:
> On Wed, Apr 29, 2015 at 12:47 PM, Andreas Cadhalpun
> <andreas.cadhalpun@googlemail.com> wrote:
>> Therefore I'm planning to discuss a possible transition from
>> Libav to FFmpeg with the maintainers of the reverse dependencies,
>> before asking the TC for a resolution.
> 
> What if one or more maintainers do not agree with you to make his
> packages break away from libav?

As I tried to imply above: If no decision between having both,
only FFmpeg, or only Libav can be reached with normal means,
we have to ask the TC.

> What result are you aiming to achieve?

I'd like to see stretch released with FFmpeg. So either FFmpeg replaces
Libav or the Security Team gets convinced that having both is acceptable.

> Splitting multimedia packages up in two groups, each one depending on
> a different implementation of the same interfaces?

This is a possible outcome, if both are allowed in stretch.

> And on the basis of what?

If both are there, any maintainer can make his own decision, probably
based on upstream preference.

> I feel that we'd better *first* decide on which one between ffmpeg and
> libav we want to keep, and drop the alternative.

I feel that it's not necessary, but possible, to make a Debian-wide
decision between FFmpeg and Libav.

Best regards,
Andreas

Acknowledgement sent to Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>:
Extra info received and forwarded to list. Copy sent to Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>. (Wed, 29 Apr 2015 18:12:19 GMT) (full text, mbox, link).

Message #298 received at 763148@bugs.debian.org (full text, mbox, reply):

Hi Jonathan,

thanks for answering my question.

On 29.04.2015 16:52, Jonathan Wiltshire wrote:
> mysql-5.5 and mariadb-10.0 in Jessie is not exactly "no problem".
> There were extensive discussions before the freeze about which of
> the *four* forks of MySQL would ship in Jessie.
>
> Bear in mind that MySQL and Maria were both already in testing at
> this point.

When I asked Moritz about MySQL and MariaDB [1] in February 2014,
MariaDB 5.5 had been in testing for just two months, while
MariaDB 10.0 went to testing only in November 2014.

> The security team understandably want to support only
> one fork. The maintainers could not agree which it should be.

This is exactl
I don't think that's a fair criterion. FFmpeg would be in testing,
if it wasn't blocked.
Now the justification for the block is that it's not in testing.
That's kind of circular.

> andy how it was with FFmpeg/Libav before the freeze.

> We eventually arranged to ship two of those four forks in Jessie
> with a view to having only one in Stretch,  easing the transition
> for users if it ends up being Maria. That aim has not changed.
> Jessie was a compromise situation.

I would have appreciated if there had been such a compromise solution
for FFmpeg/Libav as well.

> This isn't a good direct comparison with ffmpeg/libav since we do
> not have the situation of them both in testing at the moment,

I don't think that's a fair criterion. FFmpeg would be in testing,
if it wasn't blocked.
Now the justification for the block is that it's not in testing.
That's kind of circular.

> and
> I believe that should remain the case until one or the other
> becomes the obvious candidate. We do not want to end up with
> dependencies on both in testing that need to be untangled later.

That's understandable. But on the other hand, not having FFmpeg
in testing means more work elsewhere and less testing for it.

Best regards,
Andreas

1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729203#420

Acknowledgement sent to Moritz Mühlenhoff <jmm@inutil.org>:
Extra info received and forwarded to list. Copy sent to Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>. (Wed, 29 Apr 2015 18:27:11 GMT) (full text, mbox, link).

Message #303 received at 763148@bugs.debian.org (full text, mbox, reply):

Andreas Cadhalpun wrote:

> But having mysql-5.5 and mariadb-10.0 in jessie is apparently no
> problem, despite previous claims. What's the difference?

To properly migrate over a daemon they need to co-exist for a stable
release, while a lib does not. Stretch will only have one of them.

> How do you think this should go forward?

When someone made a strawpoll amongst the multimedia maintainers
last year it boiled down to "libav for jessie, since it's now to late".
You should revisit that decision now that the release cycle has started.
(Beside pkg-multimedia-maintainers, this certainly also includes
maintainers like Balint which maintain relevant multimedia apps outside of
pkg-multimedia-maintainers.)

If no convinging/clear majority can be reached, let the CTTE decide.

Having both for a year along each other will only waste people's time. Now
at the beginning of the release cycle is the time to make a decision,
not by dragging things into a year as of today. Picking one of the two
won't be any simpler in 12 months.

Cheers,
        Moritz

Acknowledgement sent to Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>:
Extra info received and forwarded to list. Copy sent to Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>. (Wed, 29 Apr 2015 18:36:04 GMT) (full text, mbox, link).

Message #308 received at 763148@bugs.debian.org (full text, mbox, reply):

Hi Moritz,

On 29.04.2015 20:22, Moritz Mühlenhoff wrote:
> Andreas Cadhalpun wrote:
> 
>> But having mysql-5.5 and mariadb-10.0 in jessie is apparently no
>> problem, despite previous claims. What's the difference?
> 
> To properly migrate over a daemon they need to co-exist for a stable
> release, while a lib does not. Stretch will only have one of them.

That makes sense, thanks for explaining.

>> How do you think this should go forward?
> 
> When someone made a strawpoll amongst the multimedia maintainers
> last year it boiled down to "libav for jessie, since it's now to late".
> You should revisit that decision now that the release cycle has started.
> (Beside pkg-multimedia-maintainers, this certainly also includes
> maintainers like Balint which maintain relevant multimedia apps outside of
> pkg-multimedia-maintainers.)
> 
> If no convinging/clear majority can be reached, let the CTTE decide.

That was my plan.

> Having both for a year along each other will only waste people's time. Now
> at the beginning of the release cycle is the time to make a decision,
> not by dragging things into a year as of today. Picking one of the two
> won't be any simpler in 12 months.

I just fear that the decision making process will take long, especially
if the TC has to get involved. (The libjpeg-turbo TC decision took 1 year.)

Having ffmpeg in testing during this time would be nice, e.g. so that people
using testing can easily compare them.

Was that not what you meant with [1]:
"It certainly possible to have them co-exist for a year or so"

Best regards,
Andreas

1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763148#134

Message #313 received at 763148@bugs.debian.org (full text, mbox, reply):

Hi Moritz,

On Wed, Apr 29, 2015 at 7:22 PM, Moritz Mühlenhoff <jmm@inutil.org> wrote:
> Having both for a year along each other will only waste people's time. Now
> at the beginning of the release cycle is the time to make a decision,
> not by dragging things into a year as of today. Picking one of the two
> won't be any simpler in 12 months.

I couldn't agree more.
I'm bringing this up to pkg-multimedia-maintainers's attention by
moving this into a separate thread on our mailing list to reduce the
noise here.

Cheers.

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

Acknowledgement sent to Moritz Mühlenhoff <jmm@inutil.org>:
Extra info received and forwarded to list. Copy sent to Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>. (Wed, 29 Apr 2015 18:48:15 GMT) (full text, mbox, link).

Message #318 received at 763148@bugs.debian.org (full text, mbox, reply):

On Wed, Apr 29, 2015 at 08:33:07PM +0200, Andreas Cadhalpun wrote:
> > Having both for a year along each other will only waste people's time. Now
> > at the beginning of the release cycle is the time to make a decision,
> > not by dragging things into a year as of today. Picking one of the two
> > won't be any simpler in 12 months.
> 
> I just fear that the decision making process will take long, especially
> if the TC has to get involved. (The libjpeg-turbo TC decision took 1 year.)
> 
> Having ffmpeg in testing during this time would be nice, e.g. so that people
> using testing can easily compare them.
> 
> Was that not what you meant with [1]:
> "It certainly possible to have them co-exist for a year or so"

Honestly at this point I don't believe we'll need a year to sort out whether
it'll be libav or ffmpeg.

I'll refrain from mentioning my personal preference for now, but IMO
one of the two is preferable in almost all aspects, so picking the lib for
stretch shouldn't take that long.

Cheers,
        Moritz

Acknowledgement sent to Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>:
Extra info received and forwarded to list. Copy sent to Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>. (Wed, 29 Apr 2015 18:51:08 GMT) (full text, mbox, link).

Message #323 received at 763148@bugs.debian.org (full text, mbox, reply):

Hi Julien,

On 29.04.2015 20:40, Julien Cristau wrote:
> On Wed, Apr 29, 2015 at 20:33:07 +0200, Andreas Cadhalpun wrote:
> 
>> Having ffmpeg in testing during this time would be nice, e.g. so that people
>> using testing can easily compare them.
>>
> Not really.  It's a library, users don't get to compare, they get to use
> whichever one is chosen by the application they're using.

It's not only a library, but also a set of command-line tools (the ffmpeg
binary package).

With these command-line tools one can check the libraries. (That's how
a large part of the upstream test-suite works.)

For example, one can verify that bugs in Libav don't exist in FFmpeg,
e.g. #783616 [1].

Best regards,
Andreas

1: https://bugs.debian.org/783616

Acknowledgement sent to Julien Cristau <jcristau@debian.org>:
Extra info received and forwarded to list. Copy sent to Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>. (Wed, 29 Apr 2015 18:54:04 GMT) (full text, mbox, link).

Message #328 received at 763148@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

On Wed, Apr 29, 2015 at 20:33:07 +0200, Andreas Cadhalpun wrote:

> Having ffmpeg in testing during this time would be nice, e.g. so that people
> using testing can easily compare them.
> 
Not really.  It's a library, users don't get to compare, they get to use
whichever one is chosen by the application they're using.

Cheers,
Julien

[signature.asc (application/pgp-signature, inline)]

Acknowledgement sent to Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>:
Extra info received and forwarded to list. Copy sent to Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>. (Wed, 29 Apr 2015 19:00:04 GMT) (full text, mbox, link).

Message #333 received at 763148@bugs.debian.org (full text, mbox, reply):

On 29.04.2015 20:47, Moritz Mühlenhoff wrote:
> On Wed, Apr 29, 2015 at 08:33:07PM +0200, Andreas Cadhalpun wrote:
>>> Having both for a year along each other will only waste people's time. Now
>>> at the beginning of the release cycle is the time to make a decision,
>>> not by dragging things into a year as of today. Picking one of the two
>>> won't be any simpler in 12 months.
>>
>> I just fear that the decision making process will take long, especially
>> if the TC has to get involved. (The libjpeg-turbo TC decision took 1 year.)
>>
>> Having ffmpeg in testing during this time would be nice, e.g. so that people
>> using testing can easily compare them.
>>
>> Was that not what you meant with [1]:
>> "It certainly possible to have them co-exist for a year or so"
> 
> Honestly at this point I don't believe we'll need a year to sort out whether
> it'll be libav or ffmpeg.
> 
> I'll refrain from mentioning my personal preference for now, but IMO
> one of the two is preferable in almost all aspects, so picking the lib for
> stretch shouldn't take that long.

OK, then I'll try start that discussion on pkg-multimedia soon.
But I'll have to take care of something else first.

Best regards,
Andreas

Information forwarded to debian-bugs-dist@lists.debian.org, Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>:
Bug#763148; Package ffmpeg. (Thu, 30 Apr 2015 09:27:10 GMT) (full text, mbox, link).

Acknowledgement sent to Julien Cristau <jcristau@debian.org>:
Extra info received and forwarded to list. Copy sent to Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>. (Thu, 30 Apr 2015 09:27:10 GMT) (full text, mbox, link).

Message #338 received at 763148@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

On Wed, Apr 29, 2015 at 20:48:50 +0200, Andreas Cadhalpun wrote:

> Hi Julien,
> 
> On 29.04.2015 20:40, Julien Cristau wrote:
> > On Wed, Apr 29, 2015 at 20:33:07 +0200, Andreas Cadhalpun wrote:
> > 
> >> Having ffmpeg in testing during this time would be nice, e.g. so that people
> >> using testing can easily compare them.
> >>
> > Not really.  It's a library, users don't get to compare, they get to use
> > whichever one is chosen by the application they're using.
> 
> It's not only a library, but also a set of command-line tools (the ffmpeg
> binary package).
> 
Those tools are entirely irrelevant to the current discussion.

Cheers,
Julien

[signature.asc (application/pgp-signature, inline)]

Acknowledgement sent to Stephan Seitz <stse+debian@fsing.rootsland.net>:
Extra info received and forwarded to list. Copy sent to Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>. (Thu, 30 Apr 2015 11:21:04 GMT) (full text, mbox, link).

Message #343 received at 763148@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

On Thu, Apr 30, 2015 at 11:24:38AM +0200, Julien Cristau wrote:
>On Wed, Apr 29, 2015 at 20:48:50 +0200, Andreas Cadhalpun wrote:
>> It's not only a library, but also a set of command-line tools (the 
>> ffmpeg binary package).
>Those tools are entirely irrelevant to the current discussion.

It may be relevant if these tools are used by other programs someone 
wants to have in Debian. For example if you want MythTV you will need 
ffmpeg.

On the other hand at least I don’t care about your discussion. The Debian 
multimedia repo exists with ffmpeg and MythTV.

Shade and sweet water!

	Stephan

-- 
| Stephan Seitz          E-Mail: stse@fsing.rootsland.net |
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |

[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>:
Bug#763148; Package ffmpeg. (Sat, 09 May 2015 09:12:04 GMT) (full text, mbox, link).

Acknowledgement sent to balint@balintreczey.hu:
Extra info received and forwarded to list. Copy sent to Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>. (Sat, 09 May 2015 09:12:04 GMT) (full text, mbox, link).

Message #348 received at 763148@bugs.debian.org (full text, mbox, reply):

Hi All,

2015-04-29 20:36 GMT+02:00 Alessio Treglia <alessio@debian.org>:
> Hi Moritz,
>
> On Wed, Apr 29, 2015 at 7:22 PM, Moritz Mühlenhoff <jmm@inutil.org> wrote:
>> Having both for a year along each other will only waste people's time. Now
>> at the beginning of the release cycle is the time to make a decision,
>> not by dragging things into a year as of today. Picking one of the two
>> won't be any simpler in 12 months.
>
> I couldn't agree more.
> I'm bringing this up to pkg-multimedia-maintainers's attention by
> moving this into a separate thread on our mailing list to reduce the
> noise here.
For the interested parties the thread starts here [1] and continues
here [2] in May.

At the moment we have 4 votes for having ffmpeg, one for having both
and zero having for libav in testing.

The votes were cast in four days starting with Alessio's email and
there were no new votes in the last five days.

Alessio also mentioned that he had an opinion five days ago, but has
not disclosed it yet [4].

Andreas Cadhalpun also provided a transition plan which would work nicely IMO.

Cheers,
Balint

[1] http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2015-April/043928.html
[2] http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2015-May/043979.html
[3] http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2015-May/043980.html
[4] http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2015-May/044089.html

Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Sun, 07 Jun 2015 07:29:05 GMT) (full text, mbox, link).

Send a report that this bug log contains spam.

Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Fri Aug 2 09:53:18 2024; Machine Name: buxtehude

Debian Bug tracking system

Debbugs is free software and licensed under the terms of the GNU Public License version 2. The current version can be obtained from https://bugs.debian.org/debbugs-source/.

Debian Bug report logs - #763148 Prevent migration to jessie

Debian Bug report logs - #763148
Prevent migration to jessie