[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild

[Alexis Ballier]

On Wed, 16 Jan 2013 12:40:02 +0000 (UTC)
"Tomas Chvatal (scarabeus)" <scarabeus@gentoo.org> wrote:

> scarabeus    13/01/16 12:40:02
> 
>   Modified:             ChangeLog
>   Added:                ffmpeg-9.ebuild
>   Removed:              ffmpeg-0.10.2-r1.ebuild
>   Log:
>   Add new virtual for 1.1/9 series. Masked. Also it has switched dep
> order as will be announced upon unmasking. 

... and since we are committing silently without any real discussion I
will switch the dep order again and announce it much later without
leaving room for discussion :)

More seriously: Why ? Who decided this ?
Let's be realistic, both upstreams claim they're better than the other
in one way or another, and let's think like serious downstreams, not
like upstream playground.

As a downstream, I can see plenty of reasons against, but none in favor
of this change:
- There are still a couple of non-trivial packages that need to be
  fixed to work with libav while I don't know any that works with libav
  but not ffmpeg.
- All (but the one discovered in Nov. 2012) of the security issues
  fixed by libav 0.8.5, released on Jan. 13 2013 were fixed in May 2012
  (!!) for ffmpeg according to the website... 8 months before...

Alexis.

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild

[Luca Barbato]

On 16/01/13 21:09, Alexis Ballier wrote:
> More seriously: Why ? Who decided this ?

I never pushed my weight over it before since as you are involved in
FFmpeg directly, I am involved in Libav directly.

Thus anything I say on this topic has a clear bias. Same goes for you.

Tomas is not related to libav beside one of his core project using it by
transition, so I would expect him to be less biased than us.

> Let's be realistic, both upstreams claim they're better than the other
> in one way or another, and let's think like serious downstreams, not
> like upstream playground.

VLC uses it since ffmpeg doesn't work with rtmp properly last time they
checked and other interesting situations.

gst-ffmpeg/gst-libav works only with libav as per upstream desire (thus
the rename)

ubuntu and debian just use Libav.

> As a downstream, I can see plenty of reasons against, but none in favor
> of this change:
> - There are still a couple of non-trivial packages that need to be
>   fixed to work with libav while I don't know any that works with libav
>   but not ffmpeg.

See above for the other way round.

> - All (but the one discovered in Nov. 2012) of the security issues
>   fixed by libav 0.8.5, released on Jan. 13 2013 were fixed in May 2012
>   (!!) for ffmpeg according to the website... 8 months before...

The security game is fun. Given the number of "additional features" the
surface impact is bigger in FFmpeg and currently all but one of the bugs
claimed as security issues originate from the same guy he claim to fix
them (sometimes the fix doesn't address the underlying issue but just
_that_ specific sample).

I'd rather avoid having another mud sliding contest.

I stopped caring about FFmpeg since somebody gave a sample of his humor
wishing my death.


Lu

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild

[Tomáš Chvátal]

Dne St 16. ledna 2013 17:09:07, Alexis Ballier napsal(a):
> On Wed, 16 Jan 2013 12:40:02 +0000 (UTC)
> 
> "Tomas Chvatal (scarabeus)" <scarabeus@gentoo.org> wrote:
> > scarabeus    13/01/16 12:40:02
> > 
> >   Modified:             ChangeLog
> >   Added:                ffmpeg-9.ebuild
> >   Removed:              ffmpeg-0.10.2-r1.ebuild
> >   Log:
> >   Add new virtual for 1.1/9 series. Masked. Also it has switched dep
> > 
> > order as will be announced upon unmasking.
> 
> ... and since we are committing silently without any real discussion I
> will switch the dep order again and announce it much later without
> leaving room for discussion :)

Did you read the msg, announced later on, i am just preparing that shit 
because now I have time. Given that its masked and does not affect existing 
installs it can stay like this forever.

Also if you read planet you would see I stated it on a blog yesterday, 
preparation of all moves take some time. Also it will be discussed on the dev 
in near future. I don't have too much of the time and sending mails to -dev 
takes some preparations if you don't want them turn into huge bikeshed.

> 
> More seriously: Why ? Who decided this ?
> Let's be realistic, both upstreams claim they're better than the other
> in one way or another, and let's think like serious downstreams, not
> like upstream playground.

I do think like serious downstream. Thus tracking what major distros do. Given 
fedora switched and debian too we ough to do it at some point too.

Also quite few upstreams are migrating and few staying so there is a tie. But 
we have to work on supporting both which currently you don't (see bellow).

> 
> As a downstream, I can see plenty of reasons against, but none in favor
> of this change:
> - There are still a couple of non-trivial packages that need to be
>   fixed to work with libav while I don't know any that works with libav
>   but not ffmpeg.

Nice from you that you didnt bother to check out if it works or not because I 
do it quite often, so does tinderbox from Diego.

Every time i bump shit I have to compile it in two virtuals just to please 
both camps. Lets not forget how carefull you were when commiting to xbmc where 
you completely fucked stable ebuild without even letting anyone know [1].

From my checking only package right now not building with stable libav is 
again XBMC (in testing only). If there is something more open bugs in bugize.

> - All (but the one discovered in Nov. 2012) of the security issues
>   fixed by libav 0.8.5, released on Jan. 13 2013 were fixed in May 2012
>   (!!) for ffmpeg according to the website... 8 months before...

So what? Checking their importance yea we ride it straight to stable on 
Gentoo, but security relevance would not deem any maintenance update only to 
be done with next proposed maintenance one (eg when there is something 
important to fix) because most of them look .

I can waste time to look the other way around and show you broken code in 
ffmpeg which happened after broken merge from libav but lets not turn this 
into a piss contest.

Basically this having two libraries hurt everyone, but both forks are on par 
and we as gentoo will provide both while preffered default will be what major 
distros use.

If you disagree with that and you don't want your lead to make that decision, 
which you and I both don't want. I don't want Luca being blamed that he is 
evil libav dev who does this just to make more share for his pet project. We 
can wait with dealing this for a bit and propose it for council meeting. We 
vote about lots and lots of stuff there and another thread about two ffmpeg 
implems on g-dev will do just fine, but it will be hell of a bikeshed :-)

Tom

[1] https://bugs.gentoo.org/show_bug.cgi?id=443006

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild

[Alexis Ballier]

On Wed, 16 Jan 2013 21:39:04 +0100
Luca Barbato <lu_zero@gentoo.org> wrote:

> On 16/01/13 21:09, Alexis Ballier wrote:
> > More seriously: Why ? Who decided this ?
> 
> I never pushed my weight over it before since as you are involved in
> FFmpeg directly, I am involved in Libav directly.

I don't know what you mean by involved directly, but ffmpeg happens to
be what I use and care about, hence I have a couple of commits there
but their number is quite ridiculous in comparison. [Actually, I should
be honored that you compare my involvement with yours :)]

> Thus anything I say on this topic has a clear bias. Same goes for you.

... but I admit I have some bias, however, I'm rather a consumer than a
developer when it comes to ffmpeg and believe we need to think as
consumers as a downstream distro.

> Tomas is not related to libav beside one of his core project using it
> by transition, so I would expect him to be less biased than us.
> 
> > Let's be realistic, both upstreams claim they're better than the
> > other in one way or another, and let's think like serious
> > downstreams, not like upstream playground.
> 
> VLC uses it since ffmpeg doesn't work with rtmp properly last time
> they checked and other interesting situations.

interesting, did they report it? OTOH, they switched _after_ the 2.0.5
release which happens to be the latest one. Since vlc is probably the
ffmpeg/libav interface the most popular in the world (due to their
windows and mac builds), I'd like to see an actual release with it and
see if there is any regression before claiming they use libav.

> gst-ffmpeg/gst-libav works only with libav as per upstream desire
> (thus the rename)

you mean use libav internally? because 'per upstream desire'
gst-ffmpeg or gst-libav always only worked with the internal libs :)
it also appears to build and work fine with ffmpeg-0.10

> ubuntu and debian just use Libav.

Speaking about bias, the maintainer happens to be part of libav core
developers and was even part of what is known as the 'ffmpeg coup' :)

> > As a downstream, I can see plenty of reasons against, but none in
> > favor of this change:
> > - There are still a couple of non-trivial packages that need to be
> >   fixed to work with libav while I don't know any that works with
> > libav but not ffmpeg.
> 
> See above for the other way round.

None of what you cited is a problem for a downstream distribution,
except maybe vlc+rtmp which should be fixed regardless.
xbmc and mplayer did not build last time I tried. xbmc will be a pain
because it uses some libavfilter features not in libav.

> > - All (but the one discovered in Nov. 2012) of the security issues
> >   fixed by libav 0.8.5, released on Jan. 13 2013 were fixed in May
> > 2012 (!!) for ffmpeg according to the website... 8 months before...
> 
> The security game is fun. Given the number of "additional features"
> the surface impact is bigger in FFmpeg and currently all but one of
> the bugs claimed as security issues originate from the same guy he
> claim to fix them (sometimes the fix doesn't address the underlying
> issue but just _that_ specific sample).

I don't want to verify this and will trust you there, but I still
don't consider 8 months to be a correct delay for handling a published
vulnerability, whatever its origin may be.

> I'd rather avoid having another mud sliding contest.
> 
> I stopped caring about FFmpeg since somebody gave a sample of his
> humor wishing my death.

This is getting personal :) I'm sure the fork didn't happen because
some day some devs woke up angry because they didn't have had their
coffee. However, I'm also sure the fork is a pain for downstream
distros and a lot of upstreams.

Alexis.

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild

[Luca Barbato]

On 16/01/13 22:31, Alexis Ballier wrote:
> interesting, did they report it? OTOH, they switched _after_ the 2.0.5
> release which happens to be the latest one. Since vlc is probably the
> ffmpeg/libav interface the most popular in the world (due to their
> windows and mac builds), I'd like to see an actual release with it and
> see if there is any regression before claiming they use libav.

Reported, dismissed as bug on their side IIRC.

>> gst-ffmpeg/gst-libav works only with libav as per upstream desire
>> (thus the rename)
> 
> you mean use libav internally? because 'per upstream desire'
> gst-ffmpeg or gst-libav always only worked with the internal libs :)
> it also appears to build and work fine with ffmpeg-0.10

To be more clear, latest gst-libav release does not build with latest
ffmpeg release, same said for the gst-libav backport.

> Speaking about bias, the maintainer happens to be part of libav core
> developers and was even part of what is known as the 'ffmpeg coup' :)

Meanwhile I preferred let people pick their poison since it is easy to
switch from one to another, in retrospect would had been better if I
just removed ffmpeg from the tree from day 0.

> None of what you cited is a problem for a downstream distribution,
> except maybe vlc+rtmp which should be fixed regardless.

> xbmc and mplayer did not build last time I tried. xbmc will be a pain
> because it uses some libavfilter features not in libav.

mplayer2 works decently here. I didn't try to look at xbmc yet.

> I don't want to verify this and will trust you there, but I still
> don't consider 8 months to be a correct delay for handling a published
> vulnerability, whatever its origin may be.

Crashes are always bad, we fix a lot of them every day, we obviously
introduce few new since we aren't perfect, calling all of them security
problems is a tad extreme in my opinion.

The problem with the "published vulnerabilities" had been usually us
being prevented from accessing the example vectors, now the situation is
way better.

> I'm sure the fork didn't happen because
> some day some devs woke up angry because they didn't have had their
> coffee. However, I'm also sure the fork is a pain for downstream
> distros and a lot of upstreams.

The rationale is on libav.org/about.html, I spent about 3 months trying
to prevent it. I failed.

lu

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild

[Alexis Ballier]

On Wed, 16 Jan 2013 22:52:52 +0100
Luca Barbato <lu_zero@gentoo.org> wrote:

> On 16/01/13 22:31, Alexis Ballier wrote:
> > interesting, did they report it? OTOH, they switched _after_ the
> > 2.0.5 release which happens to be the latest one. Since vlc is
> > probably the ffmpeg/libav interface the most popular in the world
> > (due to their windows and mac builds), I'd like to see an actual
> > release with it and see if there is any regression before claiming
> > they use libav.
> 
> Reported, dismissed as bug on their side IIRC.

Hard to blame anyone without more info nor a description of the problem,
it can even be a too quick analysis before dismissing it.

> >> gst-ffmpeg/gst-libav works only with libav as per upstream desire
> >> (thus the rename)
> > 
> > you mean use libav internally? because 'per upstream desire'
> > gst-ffmpeg or gst-libav always only worked with the internal libs :)
> > it also appears to build and work fine with ffmpeg-0.10
> 
> To be more clear, latest gst-libav release does not build with latest
> ffmpeg release, same said for the gst-libav backport.

meaning bug #447838 ??? are you kidding ?

> > Speaking about bias, the maintainer happens to be part of libav core
> > developers and was even part of what is known as the 'ffmpeg
> > coup' :)
> 
> Meanwhile I preferred let people pick their poison since it is easy to
> switch from one to another, in retrospect would had been better if I
> just removed ffmpeg from the tree from day 0.

Fortunately we're not debian and do not like when people impose their
choice on us.

> > None of what you cited is a problem for a downstream distribution,
> > except maybe vlc+rtmp which should be fixed regardless.
> 
> > xbmc and mplayer did not build last time I tried. xbmc will be a
> > pain because it uses some libavfilter features not in libav.
> 
> mplayer2 works decently here. I didn't try to look at xbmc yet.

mplayer2 is a good player but unfortunately for me it doesn't come with
a mencoder2. Being the one that did most of the porting to the recent
APIs of libav* for xbmc, I can assure you that any help is very welcome
to have a sane support for libav.
 
> > I don't want to verify this and will trust you there, but I still
> > don't consider 8 months to be a correct delay for handling a
> > published vulnerability, whatever its origin may be.
> 
> Crashes are always bad, we fix a lot of them every day, we obviously
> introduce few new since we aren't perfect, calling all of them
> security problems is a tad extreme in my opinion.

It's probably the fault of the current trend of tagging most of the
crashes as sec. issues. The problem here is that a crash fix is almost
invisible, while a CVE gets very high visibility, and leaving time to
malicious people for reinventing an attack is bad.

> The problem with the "published vulnerabilities" had been usually us
> being prevented from accessing the example vectors, now the situation
> is way better.

This is news to me, but good it improved.

[...]

A.

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild

[Samuli Suominen]

On 16/01/13 22:09, Alexis Ballier wrote:
> On Wed, 16 Jan 2013 12:40:02 +0000 (UTC)
> "Tomas Chvatal (scarabeus)" <scarabeus@gentoo.org> wrote:
>
>> scarabeus    13/01/16 12:40:02
>>
>>    Modified:             ChangeLog
>>    Added:                ffmpeg-9.ebuild
>>    Removed:              ffmpeg-0.10.2-r1.ebuild
>>    Log:
>>    Add new virtual for 1.1/9 series. Masked. Also it has switched dep
>> order as will be announced upon unmasking.
>
> ... and since we are committing silently without any real discussion I
> will switch the dep order again and announce it much later without
> leaving room for discussion :)

The tree definately isn't ready for libav so +1 from me, I almost 
changed it back myself already but to avoid stupid commit wars didn't.

I have no plans testing anything against libav anytime soon, and same 
for mplayer2 for same reasons, no mencoder. It's just another fork,
not an upgrade.

Regards,
Happy user of ffmpeg and mplayer-original

- Samuli

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild

[Markos Chandras]

On 16 January 2013 20:09, Alexis Ballier <aballier@gentoo.org> wrote:
> On Wed, 16 Jan 2013 12:40:02 +0000 (UTC)
> "Tomas Chvatal (scarabeus)" <scarabeus@gentoo.org> wrote:
>
>> scarabeus    13/01/16 12:40:02
>>
>>   Modified:             ChangeLog
>>   Added:                ffmpeg-9.ebuild
>>   Removed:              ffmpeg-0.10.2-r1.ebuild
>>   Log:
>>   Add new virtual for 1.1/9 series. Masked. Also it has switched dep
>> order as will be announced upon unmasking.
>
> ... and since we are committing silently without any real discussion I
> will switch the dep order again and announce it much later without
> leaving room for discussion :)
>
> More seriously: Why ? Who decided this ?

I agree. This is a big change so there should be a discussion about
this or at least an announcement that this is going to happen on the
Xth of February. Did you actually test that the tree is ready for
libav as the default ffmpeg provider?

-- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild

[Tomáš Chvátal]

2013/1/17 Markos Chandras <hwoarang@gentoo.org>:
> On 16 January 2013 20:09, Alexis Ballier <aballier@gentoo.org> wrote:
>> On Wed, 16 Jan 2013 12:40:02 +0000 (UTC)
>> "Tomas Chvatal (scarabeus)" <scarabeus@gentoo.org> wrote:
>>
>>> scarabeus    13/01/16 12:40:02
>>>
>>>   Modified:             ChangeLog
>>>   Added:                ffmpeg-9.ebuild
>>>   Removed:              ffmpeg-0.10.2-r1.ebuild
>>>   Log:
>>>   Add new virtual for 1.1/9 series. Masked. Also it has switched dep
>>> order as will be announced upon unmasking.
>>
>> ... and since we are committing silently without any real discussion I
>> will switch the dep order again and announce it much later without
>> leaving room for discussion :)
>>
>> More seriously: Why ? Who decided this ?
>
> I agree. This is a big change so there should be a discussion about
> this or at least an announcement that this is going to happen on the
> Xth of February. Did you actually test that the tree is ready for
> libav as the default ffmpeg provider?
>

Yep I did test it. On stable there is nothing broken and right now
even mplayer1 compiles fine.

On testing there should be nothing broken apart from xbmc, where
Alexis is one of upstream devs and he seems not to give fuck about
making it work under both.

Also Samuli broke it yesterday because he seems not to be bothered
about fixing reverse dependencies with cdio update (but again it seems
simple to test and fix which will be done when I am not working and
have time to test it properly).

So yes it works and should not pose any issues to user. I also
announced it over blog to get people report more issues they find out
so I can be really sure it works out. It turned out the mplayer1
really needs to work under both, which I patched yesterday for stable
libav and Luca today for masked libav to work.

So overall we are in green numbers if few people didn't break it on
purpose or just for the ignorance.

The only weird stuff might be for migrating users that they have to
use "emerge -C ffmpeg && emerge -1v libav libpostproc" as a postproc
is not yet split out of ffmpeg. But even that could be discussed and
we can switch to split libpostproc under both libs to have matching
deps (even ffmpeg has --disable-postrpoc switch :)).

Tom

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild

[Markos Chandras]

On 17 January 2013 09:41, Tomáš Chvátal <tomas.chvatal@gmail.com> wrote:
>> I agree. This is a big change so there should be a discussion about
>> this or at least an announcement that this is going to happen on the
>> Xth of February. Did you actually test that the tree is ready for
>> libav as the default ffmpeg provider?
>>
>
> So yes it works and should not pose any issues to user. I also
> announced it over blog to get people report more issues they find out
> so I can be really sure it works out.

Well, a blog post may not be the ideal way to reach a wide audience of
Gentoo users. It certainly would be preferred to start
a discussion in this mailing list (and/or cc'd gentoo-users). Ok since
you have tested the tree against libav, I see no problem with the
change but it is not my decision to make.

-- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild

[Ben de Groot]

[-- Attachment #1: Type: text/plain, Size: 356 bytes --]

Ideally we would have had a discussion here, and we could still have one.

On the other hand I have used libav and mplayer2 for a long time, and have
not run into any problems. The only thing missing is mencoder.

I'm not opposing this change, but I also don't know enough of the details
of upstream differences to make a strong case for our against.

Ben

[-- Attachment #2: Type: text/html, Size: 435 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild

[Alexander Berntsen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 17/01/13 12:02, Ben de Groot wrote:
> I have used libav and mplayer2 for a long time, and have not run
> into any problems. The only thing missing is mencoder.
+1


- -- 
Alexander
alexander@plaimi.net
http://plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAlD33xwACgkQRtClrXBQc7WyKwD9EK7AjiRlw4Gcmc9+Vew8fD7H
4zzoj1H48FbXCjtLqLwA/izLXX8iayZHubgcwx1azfeOpzbs1bZTKrmyu03PiZSB
=Kp7w
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild

[Tomáš Chvátal]

2013/1/17 Ben de Groot <yngwin@gentoo.org>:
> On the other hand I have used libav and mplayer2 for a long time, and have
> not run into any problems. The only thing missing is mencoder.

Which is sovled by the mplayer1 supporting libav since yesterday. :-)

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild

[Diego Elio Pettenò]

On 17/01/2013 06:31, Samuli Suominen wrote:
>>
> 
> The tree definately isn't ready for libav so +1 from me, I almost
> changed it back myself already but to avoid stupid commit wars didn't.

I disagree with "the tree isn't ready for libav" — I can add myself to
Ben and Alexander on having used libav for a long time at this point
(given I'm also one of the original split team!).

But also, if you say that the tree isn't ready because of the bugs I
opened — remember that I'm not going to test ffmpeg any time soon. I do
reserve the right to not give a damn about software whose authors
insulted me more than a few times so ffmpeg is blacklisted on my
tinderbox. All the tree is tested with libav — and most of it works
fine, with the exception of libav-9 (because of the new API).

Interestingly enough, ffmpeg-0.11/1 has mostly same problems as libav-9,
so the bugs can easily be shared across the two, so if it's not ready
for one, it can't be ready for the other.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild

[Alexis Ballier]

On Thu, 17 Jan 2013 10:41:58 +0100
Tomáš Chvátal <tomas.chvatal@gmail.com> wrote:

[...]
> On testing there should be nothing broken apart from xbmc, where
> Alexis is one of upstream devs and he seems not to give fuck about
> making it work under both.

Please check the facts before making false claims with f* words. Thank
you.

A.

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild

[Alexis Ballier]

On Thu, 17 Jan 2013 13:22:21 +0100
Diego Elio Pettenò <flameeyes@flameeyes.eu> wrote:
[...]
> But also, if you say that the tree isn't ready because of the bugs I
> opened — remember that I'm not going to test ffmpeg any time soon. I
> do reserve the right to not give a damn about software whose authors
> insulted me more than a few times so ffmpeg is blacklisted on my
> tinderbox.

Nice mix of two different hats. I liked to think the tinderbox was
something you were doing for gentoo QA, but it seems it serves also
your personal wars...

[...]

A.

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild

[Diego Elio Pettenò]

On 17/01/2013 14:19, Alexis Ballier wrote:
> Nice mix of two different hats. I liked to think the tinderbox was
> something you were doing for gentoo QA, but it seems it serves also
> your personal wars...

I'm not on payroll for either hat so I don't see any conflict with that.

The tinderbox is a _personal_ effort, among other reasons because
otherwise I would be able to force some other developers to care about
the bugs instead of closing them as NEEDINFO because they don't like the
way they are presented. And I would probably be able to demand people to
act on them instead of keeping 1500 of those bugs open at any time.

And since I'm a person, and as I said I'm not paid to do this work (the
bandwidth and hosting is sponsored by my employer, who uses libav in
production, and the rest of the running costs are on me), I can't see
how you expect me to disregard insults that have been pointed to me over
time.

ffmpeg is in the same list as paludis and will not, ever, be tested on
my boxes, as long as it's a personal effort. Are you going to pay me to
run it? If the answer is no, please fuck off or run your own.

And I also told you this before, if you want to be so scandalized by it
right now, you either have a very shallow memory or you're looking to
make a mountain of a molehill.

Finally, I would like to point out that I haven't said anything one way
or the other regarding the default — I haven't even tried to push for
the change beforehand even though that's the one I tested. I just
refuted the statement of "the tree not being ready for libav" putting on
record that there is no indication that ffmpeg's situation is much
different, as it is not currently being tested by me (and nobody else is
doing the testing, so there).

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild

[Alexis Ballier]

On Thu, 17 Jan 2013 14:26:54 +0100
Diego Elio Pettenò <flameeyes@flameeyes.eu> wrote:

[...]
> ffmpeg is in the same list as paludis and will not, ever, be tested on
> my boxes, as long as it's a personal effort. Are you going to pay me
> to run it? If the answer is no, please fuck off or run your own.

Thank you.
I was only pointing out that ffmpeg isn't a one person thing, it's much
more that this one (or more) person who insulted you. I am using it,
Gentoo is using it, some upstreams are using it, and all of them would
benefit from a tinderbox run.
What scandalizes me is that you put my work for Gentoo in the same bag
as this silly ffmpeg/libav war.

Alexis.

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild

[Alexis Ballier]

On Thu, 17 Jan 2013 10:41:58 +0100
Tomáš Chvátal <tomas.chvatal@gmail.com> wrote:
[...]
> So yes it works and should not pose any issues to user. I also
> announced it over blog to get people report more issues they find out
> so I can be really sure it works out. It turned out the mplayer1
> really needs to work under both, which I patched yesterday for stable
> libav and Luca today for masked libav to work.

And this libav-9 patch actually breaks with all non-masked version of
both libraries... I've just fixed this, but please stop this madness
breaking everything in order to be as quick as possible to make your
point...

Also, please be sure to send the patches upstream. Your patch may need
to be improved (heck, you lose some features with libav and that
patch), Luca's one would probably be accepted quickly.

Alexis.

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild

[Diego Elio Pettenò]

On 17/01/2013 15:00, Alexis Ballier wrote:
> I was only pointing out that ffmpeg isn't a one person thing, it's much
> more that this one (or more) person who insulted you.

You weren't pointing that out at all:

> 
> Nice mix of two different hats. I liked to think the tinderbox was
> something you were doing for gentoo QA, but it seems it serves also
> your personal wars...

Tell me where you pointed out "that ffmpeg isn't a one person thing" in
that phrase? Please top with the bullshit, thank you very much.

> I am using it,
> Gentoo is using it, some upstreams are using it, and all of them would
> benefit from a tinderbox run.

And all of them are invited to either decide to let me decide how to
spend my time and dime, or actually pay me for said time.

> What scandalizes me is that you put my work for Gentoo in the same bag
> as this silly ffmpeg/libav war.

I haven't. Don't put words in my mouth, or in my keyboard. I have only
said I don't want to care about ffmpeg, and I have the right not to as
NOBODY IS PAYING ME TO DO THAT KIND OF WORK.

I could realistically just stop doing any tinderboxing at all, but I
keep going. I have a steady average of 1500 bugs open at any point in
time and most of the times I'm the one catching issues .. I do that for
free, which also means you don't get to tell me what to do any more than
I get to tell you what to do.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild

[Peter Stuge]

Samuli Suominen wrote:
> I almost changed it back myself already but to avoid stupid commit
> wars didn't.

Interesting comment considering how blazing fast you were to commit
a change of the default for another forked project.


> It's just another fork, not an upgrade.

Interesting comment indeed.


//Peter

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild

[Luca Barbato]

On 17/01/13 15:07, Alexis Ballier wrote:
> On Thu, 17 Jan 2013 10:41:58 +0100
> Tomáš Chvátal <tomas.chvatal@gmail.com> wrote:
> [...]
>> So yes it works and should not pose any issues to user. I also
>> announced it over blog to get people report more issues they find out
>> so I can be really sure it works out. It turned out the mplayer1
>> really needs to work under both, which I patched yesterday for stable
>> libav and Luca today for masked libav to work.
> 
> And this libav-9 patch actually breaks with all non-masked version of
> both libraries... I've just fixed this, but please stop this madness
> breaking everything in order to be as quick as possible to make your
> point...

I guess I overlooked something, thanks for fixing it.

lu

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild

[Alexis Ballier]

On Thu, 17 Jan 2013 15:10:18 +0100
Diego Elio Pettenò <flameeyes@flameeyes.eu> wrote:

> On 17/01/2013 15:00, Alexis Ballier wrote:
> > I was only pointing out that ffmpeg isn't a one person thing, it's
> > much more that this one (or more) person who insulted you.
> 
> You weren't pointing that out at all:
> 
> > 
> > Nice mix of two different hats. I liked to think the tinderbox was
> > something you were doing for gentoo QA, but it seems it serves also
> > your personal wars...
> 
> Tell me where you pointed out "that ffmpeg isn't a one person thing"
> in that phrase? Please top with the bullshit, thank you very much.

You are playing on words and becoming aggressive. I was, indeed, not
'pointing out' but rather suggesting... and maybe it wasn't clear but I
wasn't writing about who develops it but rather who uses and benefits
from it.
I believe we all agree that ffmpeg being part of Gentoo, me caring about
it, makes it fall under Gentoo QA umbrella which in turns benefits the
whole community...

> > I am using it,
> > Gentoo is using it, some upstreams are using it, and all of them
> > would benefit from a tinderbox run.
> 
> And all of them are invited to either decide to let me decide how to
> spend my time and dime, or actually pay me for said time.
>
> > What scandalizes me is that you put my work for Gentoo in the same
> > bag as this silly ffmpeg/libav war.
> 
> I haven't. Don't put words in my mouth, or in my keyboard. I have only
> said I don't want to care about ffmpeg, and I have the right not to as
> NOBODY IS PAYING ME TO DO THAT KIND OF WORK.

It's all your right. So is mine to point out you are refusing to help
me in my gentoo work because you hate upstream of the package I'm
working on. I feel sad for being sent to one side of this silly war
just because I'm happy with ffmpeg and want to provide the alternative
(*) to our users...

[...]

(*) Alternative which I indeed still consider superior. This may change
in the future.

Alexis.

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild

[Duncan]

Diego Elio Pettenò posted on Thu, 17 Jan 2013 15:10:18 +0100 as excerpted:

> And all of them are invited to either decide to let me decide how to
> spend my time and dime, or actually pay me for said time.

To be clear I'm not in a position to offer, and I definitely respect and 
value your volunteer work, but suppose someone /was/ sufficiently 
interested in something like ffmpeg to be willing to pay for a tinderbox 
run on it.  What sort of "pay for" are we talking?  Just ballpark. 
"Beverage/dinner on me at the next conference we both attend" (or Amazon 
wish-list book) level, "week's consultancy fee" level, "month's 
consultancy-fee" level, "hire me for a year and we'll talk", or...??

Of course given the history here, I'd not blame you for placing a higher 
price on this particular package, but in general...

It occurs to me that this might be more appropriately answered on your 
blog (I get the feed), but since it came up here, I might as well ask 
here.  Answer here or there or not at all, your call, but it's something 
I've wondered occasionally when I've seen "pay me and it'd be different" 
comments, both yours and others. 

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild

[Diego Elio Pettenò]

On Fri, Jan 18, 2013 at 1:32 AM, Duncan <1i5t5.duncan@cox.net> wrote:
> To be clear I'm not in a position to offer, and I definitely respect and
> value your volunteer work, but suppose someone /was/ sufficiently
> interested in something like ffmpeg to be willing to pay for a tinderbox
> run on it.  What sort of "pay for" are we talking?

It's tricky to quantify honestly. I've been seriously thinking about
it (as those who have been reading my G+ feed today noticed), and the
question of how to quantify it is the one that I have no real answer
for.

I can give you an idea of what's involved, so that it gives an idea of
why I tend to be touchy when people complain about the way I report
bugs, or the choices of packages I make. For those who follow my blog,
part of this has been covered already, so sorry if it feels like a
re-heated soup.

First of all, there's the time involved in setting up the tinderbox
itself. Given that I can easily start from a known configuration, it
usually does not take that much of mytime to configure it — but since
keeping seeds around is pointless (they go bad too quickly), and since
changing package choices often requires cleaning up everything that
used the previously-chosen package, even if I wanted to set up a
parallel tinderbox for ffmpeg, it'd take me one or two days just of
_unmerging_ the currently-installed packages. It's not an
exaggeration, last time it took 34hr to complete a --depclean on
tbamd64. As of me writing this, tbhs64 (the stable-targeted tinderbox)
is performing a depclean, started early this morning. It's machine
time, but it needs to be monitored, so let's say that a 5% of the time
is my time, and the rest is purely the machine's.

Then there is the time to build all the packages, or at least the
involved subset — I honestly forgot how many reverse dependencies were
involved in the libav testing, but I remember that the time it took
was around five days to go through all packages (and their
dependencies). Again this is mostly machine time, but as those
following my Twitter feed know, it's not so uncommon to have a package
hogging down the queue for over 24hr if not monitored, because a test
stuck, or (in the case of mldonkey) because a prompt is requested on
the tty. If somebody has a good idea how to stop interactive prompts
without having to detach or redirect stdout to file, it'd be nice.
7.5-12.5% of the time mine, the rest the machine? Likely.

Then comes the actual timedrain: sifting through the logs, and track
down the bugs — this generally has to be done while the tinderbox run,
because otherwise you can easily get obsolete bugs. While I have
written a tool that helps me with the analysis, it only does so in the
sense of finding me which logs report failures, and pre-fills the
template for reporting a bug related to said log — it does not help me
with actually finding what's going on. And sometimes a build log shows
a failure due to another package's build mistake. Only about half the
logs that my analysis script report end up in a bug at all; for the
tinderboxes as they are, I counted in the past few months an average
of an hour a day spent on "detective work" on said logs, to get to the
bugs.

Now with a bit of luck, the amount of logs to sift through for an
ffmpeg-targeted tinderbox would be much less than those generated by
tbamd64 (which uses glibc-2.17 and gcc-4.7), so let's say we end up
with a total of 10/12 hr of work all in all? I wouldn't go as far as
ask for my going hourly rate, but especially for ffmpeg, it would come
for something a bit higher than a dinner at the next conference — more
like the travel expenses (given a conference such as FOSDEM, not
SCALE, to give an idea).

And before anybody tries to misrepresent what I wrote — I don't intend
to charge anybody for my usual tinderbox runs; they run and they'll
keep running for as long as I have time to dedicate to them. As I said
before, my employer (who's sponsoring hosting and bandwidth) uses
libav in production, so it actually influences further the fact that
the default run is libav-bound — although you could call it a
self-fulfilling prophecy, as the fact they run libav is further
influenced by the fact that they employ me, but c'est la vie.

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild

[Duncan]

Diego Elio Pettenò posted on Fri, 18 Jan 2013 02:04:50 +0100 as excerpted:

> On Fri, Jan 18, 2013 at 1:32 AM, Duncan <1i5t5.duncan@cox.net> wrote:
>> To be clear I'm not in a position to offer, and I definitely respect
>> and value your volunteer work, but suppose someone /was/ sufficiently
>> interested in something like ffmpeg to be willing to pay for a
>> tinderbox run on it.  What sort of "pay for" are we talking?
> 
> It's tricky to quantify honestly. [I] can give you an idea of what's
> involved, so that it gives an idea of why I tend to be touchy when
> people complain about the way I report bugs, or the choices of packages
> I make. For those who follow my blog, part of this has been covered
> already, so sorry if it feels like a re-heated soup.

Thanks.  Yes, part of it's rehash (I do follow the blog), but IMO there's 
quite some value in getting the information out there.  It can't hurt 
having a bit of background for the bug reports, and with any luck, it'll 
be interesting enough and make the concept real enough to get others 
considering running their own tinderboxes.

> Now with a bit of luck, the amount of logs to sift through for an
> ffmpeg-targeted tinderbox would be much less than those generated by
> tbamd64 (which uses glibc-2.17 and gcc-4.7), so let's say we end up with
> a total of 10/12 hr of work all in all? I wouldn't go as far as ask for
> my going hourly rate, but especially for ffmpeg, it would come for
> something a bit higher than a dinner at the next conference — more like
> the travel expenses (given a conference such as FOSDEM, not SCALE, to
> give an idea).

So several days of machine time, and /very/ conservatively, at least a 
work day of your time, more likely 1.5-2 workdays, maybe half a week.

Yeah, that's rather more than a dinner with beverage of choice... 
especially for something you'd rather not be working on anyway.

At least readers can have some ballpark idea of what's involved now, both 
from you personally, and what the cost of a sponsored run might look like.

> And before anybody tries to misrepresent what I wrote — I don't intend
> to charge anybody for my usual tinderbox runs; they run and they'll keep
> running for as long as I have time to dedicate to them.

Thanks for the answer.  With any luck, someone out there will find the 
information useful and you'll get a contact or two offering to sponsor a 
run, now that there's a bit more information out there, more publicly 
available.  A few more tinderbox runs and the resulting fixes certainly 
won't hurt gentoo's health, either, so everyone benefits. =:^)

One more question.  I've read about various tinderbox runs, and now we 
know they take several days of machine time plus say 1-2 (surely more for 
the really involved stuff, glibc and gcc touch about everything...) days 
of your time.

Are you queued up with tinderbox runs, or is there room for more demand?  
If someone like Shuttleworth came along and offered to sponsor you to 
work on gentoo and tinderboxes full time, how far up could it scale 
before it required more people, and would there be ever more tinderbox 
possibilities or would the law of diminishing returns kick in?  Would you 
consider that or find it too boring or depressing to do full time?

Reworded, how well does it scale, and how close are you/we to a knee, 
beyond that of your limited volunteer time, at least?

FWIW, my own ~amd64/~x86 deployments are REMARKABLY smoother now than in 
the past, and I know a lot of it is due to your tinderbox runs on new gcc/
glibc, for instance, as well as your work and that of others on
--as-needed and similar.  (The work of Zac and others on portage, smarter 
config-protect, etc, has helped dramatically lower my "maintenance time 
cost" as well, and there have been many other gentoo improvements over 
the years, with EAPI-5 now one of the latest. Newbie gentooers these days 
haven't a clue, no idea what it's like compiling "a mile in the snow, 
uphill both ways...!" =:^)

So I know I've directly benefited from your tinderbox runs and other 
projects you've done, and I really do appreciate it, especially as I know 
much of it is volunteer, tho some is work related but benefits gentoo as 
well.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-dev] On tinderboxing

[Diego Elio Pettenò]

On 18/01/2013 07:12, Duncan wrote:
>> Now with a bit of luck, the amount of logs to sift through for an
>> ffmpeg-targeted tinderbox would be much less than those generated by
>> tbamd64 (which uses glibc-2.17 and gcc-4.7), so let's say we end up with
>> a total of 10/12 hr of work all in all? I wouldn't go as far as ask for
>> my going hourly rate, but especially for ffmpeg, it would come for
>> something a bit higher than a dinner at the next conference — more like
>> the travel expenses (given a conference such as FOSDEM, not SCALE, to
>> give an idea).
> 
> So several days of machine time, and /very/ conservatively, at least a 
> work day of your time, more likely 1.5-2 workdays, maybe half a week.

Yes that sounds about right about timing.

> One more question.  I've read about various tinderbox runs, and now we 
> know they take several days of machine time plus say 1-2 (surely more for 
> the really involved stuff, glibc and gcc touch about everything...) days 
> of your time.

It gets trickier with gcc and glibc, because package A can stop package
B, C, D and E from merging if it fails, so a single run never is enough
for them...

> Are you queued up with tinderbox runs, or is there room for more demand?  

I've got one run that is queued that I'm not running yet which is the
pkgconf one — I'm considering setting up a clone of tbamd64 for that
since the gcc/glibc/automake one right now it's taking a long time.

> If someone like Shuttleworth came along and offered to sponsor you to 
> work on gentoo and tinderboxes full time, how far up could it scale 
> before it required more people, and would there be ever more tinderbox 
> possibilities or would the law of diminishing returns kick in?  Would you 
> consider that or find it too boring or depressing to do full time?

I'm not sure honestly if we're not very near already to that point of
diminishing returns. For sure, if I was paid to do tinderboxing full
time I would be spending more time on automating. In particular, having
a quick way to search for open bugs for the package from the analysis
interface would cut the time I spend on it considerably.

While some people have complained about the lack of attached logs, I'm
not going to focus on that just yet because for so many of the logs, it
would require compressing them with xz and even then they might not fit,
so it's not something I see much use for.

One bothersome thing is that a lot of the current process relies on me
keeping in mind packages and patterns I've seen before. You can guess
it's not an easy walk to scale to multiple people this way. So fixing
long-standing bugs to remove "not-so-false positives" that were already
filed two years ago might be of help.

Right now I guess one of the biggest wastes of time is the doc USE flag
that I enabled globally on the tinderbox, to catch Ruby packages'
failures, and is causing a bunch of other packages to fail as well as
those conditionals are rarely tested at all.

> So I know I've directly benefited from your tinderbox runs and other 
> projects you've done, and I really do appreciate it, especially as I know 
> much of it is volunteer, tho some is work related but benefits gentoo as 
> well.

I'm glad you feel the tinderbox has helped — sometimes I'm honestly not
sure myself. But a lot of the work that is done there couldn't be
possible without things like IUSE defaults and REQUIRED_USE, as those
used to waste much much more of my time just to follow the right
dependencies to be aable to merge the packages. So I think Zac and the
other Portage developers deserve most of the cheers there, as I've
shown, I mostly just pour in the time.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild

[Peter Stuge]

Tomáš Chvátal wrote:
> we as gentoo will provide both while preffered default will be what
> major distros use.

What kind of careless mainstream attitude is that? Really?

I mean: You are saying that given two options, Gentoo will do
whatever "major distros" are doing.

(Never mind that Gentoo *is* a major distro, and whatever Gentoo does
generates collective bias just like whatever any other distro does.)


How about making an informed decision instead?

Oops, I forgot - that would mean actually having to *get informed* first.

"We as gentoo" must certainly avoid getting informed at all cost!!!!111oneone

Are you *really* quite serious? Please explain yourself.


> If you disagree with that and you don't want your lead to make that decision

Hm? Where can I learn more about the "lead" ? So it is a single
person's decision, and not "we as gentoo" that decides? I'd like to
understand how this decision making process actually works. Does
anyone know?


> which you and I both don't want.

Guess what - I have been on the receiving end of the arguably
insanely lame mainstream attitude that you support, and honestly

it fucking broke my heart

that people working on Linux distributions (it wasn't just Gentoo,
it was *every* distro) would be so genuinely uninterested in what
happens upstream, especially at a time where a downstream decision
may carry a bit of extra weight.

I do not want that.

(Around the time this happened to me I wrote roughly the same in a
private email to developers of another distribution which shall
remain unnamed. I found that email in a pastebin a few days later.)


It is long since clear to me that I have much too high expectations
on people.

But are you *REALLY* not able to do *any* better than "default will
be what major distros use" ?

Seriously?


//Peter

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild

[Maciej Mrozowski]

[-- Attachment #1: Type: text/plain, Size: 2370 bytes --]

On Thursday 07 of February 2013 06:52:44 Peter Stuge wrote:

> Tomáš Chvátal wrote:
> > we as gentoo will provide both while preffered default will be what
> > major distros use.
> 
> What kind of careless mainstream attitude is that? Really?

Quite the opposite, decision to use implementation A over B was taken with 
utmost care for user in mind.

> I mean: You are saying that given two options, Gentoo will do
> whatever "major distros" are doing.
> 
> (Never mind that Gentoo *is* a major distro, and whatever Gentoo does
> generates collective bias just like whatever any other distro does.)

We are not, let's not go too far, please.

> Oops, I forgot - that would mean actually having to *get informed* first.
> 
> "We as gentoo" must certainly avoid getting informed at all
> cost!!!!111oneone
> 
> Are you *really* quite serious? Please explain yourself.
>
> > If you disagree with that and you don't want your lead to make that
> > decision
> Hm? Where can I learn more about the "lead" ? So it is a single
> person's decision, and not "we as gentoo" that decides? I'd like to
> understand how this decision making process actually works. Does
> anyone know?

It depends - in distro-wide, package-tree-wide matters we have Gentoo Council. 
In local matters like this - who does the job decides. Tomáš does the job - he 
decides.

> > which you and I both don't want.
> 
> Guess what - I have been on the receiving end of the arguably
> insanely lame mainstream attitude that you support, and honestly
> 
> it fucking broke my heart
> that people working on Linux distributions (it wasn't just Gentoo,
> it was *every* distro) would be so genuinely uninterested in what
> happens upstream, especially at a time where a downstream decision
> may carry a bit of extra weight.
>
> I do not want that.
> 
> (Around the time this happened to me I wrote roughly the same in a
> private email to developers of another distribution which shall
> remain unnamed. I found that email in a pastebin a few days later.)
> 
> 
> It is long since clear to me that I have much too high expectations
> on people.
> 
> But are you *REALLY* not able to do *any* better than "default will
> be what major distros use" ?
> 
> Seriously?

Seriously you should take a deep breath, walk a dog maybe :)

regards
MM

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild

[Alexis Ballier]

On Fri, 08 Feb 2013 22:41:04 +0100
Maciej Mrozowski <reavertm@gmail.com> wrote:

> On Thursday 07 of February 2013 06:52:44 Peter Stuge wrote:
> 
> > Tomáš Chvátal wrote:
> > > we as gentoo will provide both while preffered default will be
> > > what major distros use.
> > 
> > What kind of careless mainstream attitude is that? Really?
> 
> Quite the opposite, decision to use implementation A over B was taken
> with utmost care for user in mind.

Not really. I was promised a discussion that hasn't happened yet.

[...]
> > > If you disagree with that and you don't want your lead to make
> > > that decision
> > Hm? Where can I learn more about the "lead" ? So it is a single
> > person's decision, and not "we as gentoo" that decides? I'd like to
> > understand how this decision making process actually works. Does
> > anyone know?
> 
> It depends - in distro-wide, package-tree-wide matters we have Gentoo
> Council. In local matters like this - who does the job decides. Tomáš
> does the job - he decides.

Everyone can do the job to switch defaults :)

A.

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild

[Luca Barbato]

On 08/02/13 22:46, Alexis Ballier wrote:
> On Fri, 08 Feb 2013 22:41:04 +0100
> Maciej Mrozowski <reavertm@gmail.com> wrote:
> 
>> On Thursday 07 of February 2013 06:52:44 Peter Stuge wrote:
>>
>>> Tomáš Chvátal wrote:
>>>> we as gentoo will provide both while preffered default will be
>>>> what major distros use.
>>>
>>> What kind of careless mainstream attitude is that? Really?
>>
>> Quite the opposite, decision to use implementation A over B was taken
>> with utmost care for user in mind.
> 
> Not really. I was promised a discussion that hasn't happened yet.

I'm available for discussion anytime, I got a little busy in the past
days and I will busy the next 3 days, but I should be available today
evening or now.

I stated already what I think about the whole discussion in a blog post.

To summarize it my take is quite simple, Libav leads the way regarding
the main API, it offers a more compact surface for attacks if you are
really concerned about security and usually it is a little more compact
and a bit more tested over a wider range of architectures.

I'm not for removing ffmpeg overnight since there are features that
might be of use and I'm not so hypocrite to value diversity only when it
is in favor of my interests.

That said as long the two project are compatible having one or another
as default is just a matter of making our life easier.

I'm upstream for Libav and a good number of Libav developers are Gentoo
users, including Gentoo on special platforms (e.g. aarch64).

Few large projects such as VLC and Gstreamer switched to Libav as their
default.

Since Libav is the no-frills variant, notwithstanding the interesting
campaign of "we have more security11ein!" less stuff should break since
it is usually more tested and once we gather the samples triggering a
crash usually we do not stop preventing that single crash but the whole
class of possible defect (see my work on mov as an example).

I cannot and will not say that Libav is perfect or that no bugs are
introduced on our side and other outlandish statements, but within my
biased point of view I would expect a better experience for the user not
caring about which library to use.

If you want to discuss on #gentoo-media ping me within 30 min or in 2 hours.

I hope somebody not Libav nor FFmpeg committer could come up with a
pros-cons list.

lu

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild

[Rich Freeman]

On Sat, Feb 9, 2013 at 9:12 AM, Luca Barbato <lu_zero@gentoo.org> wrote:
> I hope somebody not Libav nor FFmpeg committer could come up with a
> pros-cons list.

++, but frankly the committers are probably in the best place to do
any evaluation even if they likely have some bias.  If you wanted to
delve into the merits of portage vs paludis you'd be far more informed
by a discussion between the respective devs (even if flames are
involved) than listening to some Ubuntu users go on about which ones
were the ricers. Keeping things civil of course is desirable all the
same.

A wiki page might be a good place for this.  Perhaps we should have
some category for point-in-time analyses/evaluations/etc when things
like this come up.  A page like this might be something that gets
attention from the linux community in general.  If we want it to be
anything other than a raging flamewar it might require moderation, and
a lot of sticking to the facts and looking at it pragmatically from a
"what makes sense for a distro" standpoint rather than "which is the
better project" standpoint.

Rich

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild

[Alexis Ballier]

On Sat, 09 Feb 2013 15:12:15 +0100
Luca Barbato <lu_zero@gentoo.org> wrote:

> On 08/02/13 22:46, Alexis Ballier wrote:
> > On Fri, 08 Feb 2013 22:41:04 +0100
> > Maciej Mrozowski <reavertm@gmail.com> wrote:
> > 
> >> On Thursday 07 of February 2013 06:52:44 Peter Stuge wrote:
> >>
> >>> Tomáš Chvátal wrote:
> >>>> we as gentoo will provide both while preffered default will be
> >>>> what major distros use.
> >>>
> >>> What kind of careless mainstream attitude is that? Really?
> >>
> >> Quite the opposite, decision to use implementation A over B was
> >> taken with utmost care for user in mind.
> > 
> > Not really. I was promised a discussion that hasn't happened yet.
> 
> I'm available for discussion anytime, I got a little busy in the past
> days and I will busy the next 3 days, but I should be available today
> evening or now.

Sorry, I was away this week end...

> I stated already what I think about the whole discussion in a blog
> post.

I'm not fond of discussions via blog posts and do not think it is
the right media. I wrote one only to make it clear the decision was
not anything near a general consensus, when Tomás made it sound like it
was.

> To summarize it my take is quite simple, Libav leads the way regarding
> the main API,

This is only because libav people do not care at all about what FFmpeg
defines, while FFmpeg seems to care more about its consumers and users
by trying to provide a compatible ABI and API. Moreover, this is not
true at all when it comes to the parts where supporting both forks is
painful: libavfilter and audio resampling. It is pretty clear that the
audio resampling wheel was reinvented on the libav part, with a
different library name and in 95% of its use cases going from ffmpeg's
audio resampling to libav's is mainly a matter of 'sed s/swr/avr/'.
Some parts of libavfilter also appeared later in libav, sometimes with
a slightly different API, making it really awful to support both forks
in applications.
(I'm still looking forward a patch for xbmc and upstreamed patches for 
mplayer btw)

> it offers a more compact surface for attacks if you are
> really concerned about security and usually it is a little more
> compact

If you mean that ffmpeg is libav + ffmpeg additions, then yes.
However, if you are concerned by a more compact surface, then libav is
not the right answer: you can very well disable selected codecs,
(de)muxers, etc at build time. I even started to work on reflecting this
into an ebuild some years ago before reaching the conclusion that it
would be confusing for little to no gain. This can of course be done if
there is some demand, but so far I have not seen any.

It is funny to see how libav ignores completely ffmpeg even for
bugfixes, I stumbled over this recently and it sounded familiar:
http://git.libav.org/?p=libav.git;a=commitdiff;h=89f11f498b9c15bc71494a11a7ec560f4adf630d
vs
http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=1af91978dbab35ba9fdede187577c00d643ae33b
now, you can look at the dates, there's a one year lag in libav for
reinventing the same bugfix. This is for a format almost nobody uses,
but in any case I do not consider this attitude sane.

> and a bit more tested over a wider range of architectures.

If you are talking about fate, then I cannot comment. fate started
before the split, so I assume the owners of said test machines took
them within their respective fork.

> I'm not for removing ffmpeg overnight since there are features that
> might be of use and I'm not so hypocrite to value diversity only when
> it is in favor of my interests.

Nobody talked about removing anything :)

> That said as long the two project are compatible having one or another
> as default is just a matter of making our life easier.

I fully agree there, but you should be careful with who you include in
'our'. In the case of a default then it is clearly 'the users'. Now,
considering there are a couple (very few) of packages that do not
compile with libav, do you consider having it as default a good idea?
Those packages can very well be fixed, but if patches do not go
upstream, this is not going to work in the long term. Also, the only
reason why I have not pinned those packages to depend only on
media-video/ffmpeg is because libav is not the default (not entirely
true btw, see later), meaning those that use libav are those that are
willing to help and know what they are doing. If people are to get
libav by default and then hit compile failures to be told to use
ffmpeg, then it is QA 101 that these packages should be depending on
media-video/ffmpeg.

[...]
> Few large projects such as VLC and Gstreamer switched to Libav as
> their default.

... and chrome, mplayer, xbmc use ffmpeg :=)
also as I said in another email, I have yet to see a libav based vlc
release.

> Since Libav is the no-frills variant, notwithstanding the interesting
> campaign of "we have more security11ein!" less stuff should break
> since it is usually more tested and once we gather the samples
> triggering a crash usually we do not stop preventing that single
> crash but the whole class of possible defect (see my work on mov as
> an example).

Probably true, but I still consider a quick fix disabling the
vulnerability to be released quickly is a good thing. A complete
rework and fix can be done later, but users should not be exposed for
the sake of being perfect. That is what happens with FFmpeg merging from
libav. It is, however, sad and annoying to see it done like that
(claiming having fixed it and then having a better fix coming from
those you first claimed you were better).

[...]
> I hope somebody not Libav nor FFmpeg committer could come up with a
> pros-cons list.

By the way, I do not know why you still consider me a FFmpeg committer,
of course I can git clone and commit but someone has to push for me.
You should probably search me in FFmpeg's git log, the only things I
have done is the usual downstream patches going upstream and writing,
years before the split, a qtrle encoder I needed for some course I was
teaching.
Also, I never understood why you consider Tomás to be neutral: He has
been playing with libav almost from day 1, adding the virtual/ffmpeg
mess (which was solved since then but it was a real mess wrt useflags),
made mplayer use libav as its internal version in our ebuilds despite
upstream using ffmpeg (the point of the internal version is to be the
same as upstream, so I had to finally do the only sane thing by making
it use external ffmpeg, and then nobody cared about porting it to libav
until very recently), introduced the libpostproc mess and subtly used
the need to change some packages' deps to put libav as the leftmost
choice (ie default), insulted me because I did the work of porting a
package to recent ffmpeg versions while not understanding this leaves
only little work to also support recent libav versions...

These two posts are interesting for anyone wanting to understand the
situation also (1st more from ffmpeg side and 2nd more from libav's):
http://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html
http://codecs.multimedia.cx/?p=370

Alexis.

Discussing defaults (Was: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild)

[Luca Barbato]

On 11/02/13 03:01, Alexis Ballier wrote:
> Sorry, I was away this week end...

Not a problem, I should be reachable anytime today.

> This is only because libav people do not care at all about what FFmpeg
> defines, while FFmpeg seems to care more about its consumers and users
> by trying to provide a compatible ABI and API.

The reasons about that could be multiple, the facts are those. If you
want you application to run in both you pick the Libav API.

> Moreover, this is not
> true at all when it comes to the parts where supporting both forks is
> painful: libavfilter and audio resampling. It is pretty clear that the
> audio resampling wheel was reinvented on the libav part, with a
> different library name and in 95% of its use cases going from ffmpeg's
> audio resampling to libav's is mainly a matter of 'sed s/swr/avr/'.

Not really, the resample library idea was brewing for long even
pre-fork, it got released first on FFmpeg because there is this bulimic
tendency to add more features in order to be compelling in FFmpeg.

I said already what happened when I started to develop the pulse capture
and the generic segmenter in my github as another example of stuff
developed by unrelated people and curiously landing before deemed ready
by the author in ffmpeg git. (prores could be considered yet another
funny example).

> Some parts of libavfilter also appeared later in libav, sometimes with
> a slightly different API, making it really awful to support both forks
> in applications.

libavfilter is deemed still not ready for general consumption in Libav
and just the set of calls that won't change (hopefully) in the future
are provided. Meanwhile we are trying to make the whole buffer
management less copy-happy and a little more rational.

(not sure if you tried to use libavfilter but it is a _bit_ hard to use
if compared to vlc filter layer and such)

> (I'm still looking forward a patch for xbmc and upstreamed patches for 
> mplayer btw)

I might spend a little time.

>> it offers a more compact surface for attacks if you are
>> really concerned about security and usually it is a little more
>> compact
> 
> If you mean that ffmpeg is libav + ffmpeg additions, then yes.
> However, if you are concerned by a more compact surface, then libav is
> not the right answer: you can very well disable selected codecs,
> (de)muxers, etc at build time. I even started to work on reflecting this
> into an ebuild some years ago before reaching the conclusion that it
> would be confusing for little to no gain. This can of course be done if
> there is some demand, but so far I have not seen any.

The ebuild supports extra parameters for that specific purpose.

> It is funny to see how libav ignores completely ffmpeg even for
> bugfixes, I stumbled over this recently and it sounded familiar:
> http://git.libav.org/?p=libav.git;a=commitdiff;h=89f11f498b9c15bc71494a11a7ec560f4adf630d
> vs
> http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=1af91978dbab35ba9fdede187577c00d643ae33b
> now, you can look at the dates, there's a one year lag in libav for
> reinventing the same bugfix. This is for a format almost nobody uses,
> but in any case I do not consider this attitude sane.

Nobody is perfect and not everybody has the time to track another
project tree every day.

>> and a bit more tested over a wider range of architectures.
> 
> If you are talking about fate, then I cannot comment. fate started
> before the split, so I assume the owners of said test machines took
> them within their respective fork.

That speaks a *bit* about the general support maybe?


> I fully agree there, but you should be careful with who you include in
> 'our'. In the case of a default then it is clearly 'the users'. Now,
> considering there are a couple (very few) of packages that do not
> compile with libav, do you consider having it as default a good idea?

I have no opinion, I stayed out of the discussion and decision about
that before because I know I have a bias. I let other people decide.

> Those packages can very well be fixed, but if patches do not go
> upstream, this is not going to work in the long term. Also, the only
> reason why I have not pinned those packages to depend only on
> media-video/ffmpeg is because libav is not the default (not entirely
> true btw, see later), meaning those that use libav are those that are
> willing to help and know what they are doing. If people are to get
> libav by default and then hit compile failures to be told to use
> ffmpeg, then it is QA 101 that these packages should be depending on
> media-video/ffmpeg.

You can, if you really want, offset ffmpeg so it doesn't clash with Libav.


> ... and chrome, mplayer, xbmc use ffmpeg :=)

Chrome uses its own fork, reverting some changes form FFmpeg and picking
what they deem useful.

mplayer changes ffmpeg when they need something as they please

xbmc used the new&improved libavfilter API to access swscale, the
restricted api seems to work just fine.

 > Probably true, but I still consider a quick fix disabling the
> vulnerability to be released quickly is a good thing.

No, it is in general a really stupid idea. You are basically telling the
interested attackers where the problem is. Then the attacker does +1 and
you have your new, freshly installed application compromised.

It is the _worst_ possible service you could do.

Think about a random rpc system with 4 calls that are similar and go
down the same codepaths, some fuzzer discovers that sending a message
with a certain shape let you crash the application.

The fix pushed and published with much fanfare is "if $shape then error"
for that specific rpc call.
Pity that that similar shapes would crash the other rpc calls, thus
anybody with interest in crashing the application have a good example on
how to do that.

Unrelated to the discussion please do not do that in any project you
contribute. It is that _bad_


> By the way, I do not know why you still consider me a FFmpeg committer,
> of course I can git clone and commit but someone has to push for me.

I thought you had the commit since svn time, I don't recall if I
suggested it myself or other did.

> Also, I never understood why you consider Tomás to be neutral

I can't say about him, he never sent patches to us and he volunteer to
do the virtual when I said that I'd rather have somebody else not
related to the project.

> These two posts are interesting for anyone wanting to understand the
> situation also (1st more from ffmpeg side and 2nd more from libav's):
> http://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html
> http://codecs.multimedia.cx/?p=370

First one from one of the main ffmpeg committers nowadays the second
from the main codec reverse engineer.

lu

Re: Discussing defaults (Was: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild)

[Alexis Ballier]

On Mon, 11 Feb 2013 12:25:36 +0100
Luca Barbato <lu_zero@gentoo.org> wrote:

> On 11/02/13 03:01, Alexis Ballier wrote:
> > Sorry, I was away this week end...
> 
> Not a problem, I should be reachable anytime today.
> 

Will ping you.

> > This is only because libav people do not care at all about what
> > FFmpeg defines, while FFmpeg seems to care more about its consumers
> > and users by trying to provide a compatible ABI and API.
> 
> The reasons about that could be multiple, the facts are those. If you
> want you application to run in both you pick the Libav API.

Well, then this raises the question: If libav does not care about what
is done around it, why should we care about libav?

> > Moreover, this is not
> > true at all when it comes to the parts where supporting both forks
> > is painful: libavfilter and audio resampling. It is pretty clear
> > that the audio resampling wheel was reinvented on the libav part,
> > with a different library name and in 95% of its use cases going
> > from ffmpeg's audio resampling to libav's is mainly a matter of
> > 'sed s/swr/avr/'.
> 
> Not really, the resample library idea was brewing for long even
> pre-fork, it got released first on FFmpeg because there is this
> bulimic tendency to add more features in order to be compelling in
> FFmpeg.

There was a need for it, FFmpeg made it available with 0.10, one year
before libav-9. Why not re-using libswr into libav, possibly reworking
it entirely but offering a compatible API? This all sounded to me like
'we do not care, users and applications can take the mess, it is not
our problem'.
There is a problem we are facing today: Some audio decoders started to
output planar audio when historically ffmpeg/libav audio decoders
produced only iterleaved audio, how do you suggest to fix this in
applications? Manually converting planar audio to interleaved (ala
mplayer)? This does not seem very future-proof, this will have to be
adapted everytime a new format is added (which will not change lib
major and thus break application at runtime for poor usage of the
provided API). Or maybe use a library as a fallback that ensures you it
will be able to convert any audio format produced by ffmpeg/libav to
what you need (ala xbmc)? Which one to chose? If I want to support
ffmpeg then I have to use libswr, because that is the one that has this
property; If I want to support libav, then I have to use libavr... All
of this because ~10 people cannot work together, well, really, thank
you :)


> I said already what happened when I started to develop the pulse
> capture and the generic segmenter in my github as another example of
> stuff developed by unrelated people and curiously landing before
> deemed ready by the author in ffmpeg git. (prores could be considered
> yet another funny example).

Can you point out any important problem? Otherwise, this is simply
how open source work: this has been published with a free enough
license, if I were working on these parts I'd not start from scratch
but from the code available to me... If you want to avoid this, don't
publish it or publish it with a restrictive license and relicense your
code once pushing to libav.
Another funny example are the multithreaded decoders (ffmpeg-mt),
which was one of the main publicity material at the beginning of libav,
and suffered from numerous problems in the early days... nevertheless it
was merged by libav. You are criticizing something that has been done on
both sides :)

> > Some parts of libavfilter also appeared later in libav, sometimes
> > with a slightly different API, making it really awful to support
> > both forks in applications.
> 
> libavfilter is deemed still not ready for general consumption in Libav
> and just the set of calls that won't change (hopefully) in the future
> are provided. Meanwhile we are trying to make the whole buffer
> management less copy-happy and a little more rational.
> 
> (not sure if you tried to use libavfilter but it is a _bit_ hard to
> use if compared to vlc filter layer and such)

Yes, well, if forces were not scattered due to the split then I'm
pretty sure libavfilter would be in a much better state. IIRC, ffmpeg's
libavfilter is much more 'copy-less' than current libav's version.

[...]
> > It is funny to see how libav ignores completely ffmpeg even for
> > bugfixes, I stumbled over this recently and it sounded familiar:
> > http://git.libav.org/?p=libav.git;a=commitdiff;h=89f11f498b9c15bc71494a11a7ec560f4adf630d
> > vs
> > http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=1af91978dbab35ba9fdede187577c00d643ae33b
> > now, you can look at the dates, there's a one year lag in libav for
> > reinventing the same bugfix. This is for a format almost nobody
> > uses, but in any case I do not consider this attitude sane.
> 
> Nobody is perfect and not everybody has the time to track another
> project tree every day.

As a Gentoo developer, if you notice a bug in a package, usually the
first thing you do is pull upstream's trunk repo and see if there is a
fix available. If you don't do that, you may just be wasting your time.
Maybe if the time spent reinventing the wheel was spent more
efficiently by looking at what is done in FFmpeg, then more important
improvements could be achieved... 

> >> and a bit more tested over a wider range of architectures.
> > 
> > If you are talking about fate, then I cannot comment. fate started
> > before the split, so I assume the owners of said test machines took
> > them within their respective fork.
> 
> That speaks a *bit* about the general support maybe?

fate is quite complete on the ffmpeg side too. For me, this speaks more
about a useless scattering of forces than anything else...

> > I fully agree there, but you should be careful with who you include
> > in 'our'. In the case of a default then it is clearly 'the users'.
> > Now, considering there are a couple (very few) of packages that do
> > not compile with libav, do you consider having it as default a good
> > idea?
> 
> I have no opinion, I stayed out of the discussion and decision about
> that before because I know I have a bias. I let other people decide.

Note: If pro-libav people would be doing the work of fixing the tree
and ensuring *everything* works with libav I would not mind at all what
the default is. So far, I have been doing most of the porting work
since years, there are packages still not working with libav-0.8, the
introduction of some libav stuff in the tree caused problems
(virtual/ffmpeg, libpostproc; nothing inherent to libav, its just it
was poorly done), there are still numerous patches to support libav
(mainly because of some libavutil headers missing). I consider FFmpeg
superior, but can understand there are different opinions, however, if
this is to lower the tree quality then it is obvious libav shouldn't be
the default.

> > Those packages can very well be fixed, but if patches do not go
> > upstream, this is not going to work in the long term. Also, the only
> > reason why I have not pinned those packages to depend only on
> > media-video/ffmpeg is because libav is not the default (not entirely
> > true btw, see later), meaning those that use libav are those that
> > are willing to help and know what they are doing. If people are to
> > get libav by default and then hit compile failures to be told to use
> > ffmpeg, then it is QA 101 that these packages should be depending on
> > media-video/ffmpeg.
> 
> You can, if you really want, offset ffmpeg so it doesn't clash with
> Libav.

Ahahah :) Or maybe, despite the claims of some libav devs, libav should
realize they are the actual fork (this is now pretty clear since the
takeover failed and ffmpeg didn't collapse...) and also rename their
libraries so that the internal libav/ffmpeg fights would not affect
their users anymore and projects could use what they think best...


[...]
>  > Probably true, but I still consider a quick fix disabling the
> > vulnerability to be released quickly is a good thing.
> 
> No, it is in general a really stupid idea. You are basically telling
> the interested attackers where the problem is. Then the attacker does
> +1 and you have your new, freshly installed application compromised.
> 
> It is the _worst_ possible service you could do.
> 
> Think about a random rpc system with 4 calls that are similar and go
> down the same codepaths, some fuzzer discovers that sending a message
> with a certain shape let you crash the application.
> 
> The fix pushed and published with much fanfare is "if $shape then
> error" for that specific rpc call.
> Pity that that similar shapes would crash the other rpc calls, thus
> anybody with interest in crashing the application have a good example
> on how to do that.
> 
> Unrelated to the discussion please do not do that in any project you
> contribute. It is that _bad_

Fully agree, but a quick fix can very well be 'if overflow then error'
on the common code path, disabling completely the vulnerability while
likely rejecting valid requests too (that never worked) and then a
complete fix would be to rework the code so that there cannot be an
overflow...

Alexis.

Re: Discussing defaults (Was: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild)

[Peter Stuge]

Alexis,

Alexis Ballier wrote:
> All of this because ~10 people cannot work together, well, really,
> thank you :)

Do you have experience from being in a similar situation? You are
being quite judgemental.

There are absolutely situations where people so different that
cooperation simply can't work. It's pretty lame, but unless you
yourself participate at least on the same level as everyone else
(on both sides) you really don't get much of a say.

It's easy to tell people to "stop fighting, just get along" - but
I believ that intentional fighting is quite rare. It's more likely
about trying to make one's point.

That requires communication, but communication is not always
possible. (I don't mean transmissions back and forth, I mean
desire to understand the transmissions.)

For a long time I idealized open source as being an ideal community,
where communication always worked because everyone wanted it to. But
that's unfortunately not at all the case.


> Can you point out any important problem?

I suppose the problem is that "it is not done yet" like Greg
sometimes says about things that are being worked on in the kernel.

Of course when a work-in-progress is published and someone
desperately wants to use it they will try to use it as soon as
possible, and if they are unhelpful they will complain and/or run
off in their own direction without receiving anyone's communication.

If this has happened to you, you will know that such events teach you
never to do any work in the open, ie. only publish code when you
think that it is completely done. On the other hand you may still
want to have feedback during your work. A perfect conflict of
interest, which is quite annoying and distracting.


> how open source work

And how it sometimes doesn't work at all. I mean: It is not useful.

In an ideal world people would work more together. Sometimes that
simply isn't possible.


> > I have no opinion, I stayed out of the discussion and decision about
> > that before because I know I have a bias. I let other people decide.
> 
> Note: If pro-libav people would be doing the work of fixing the tree
> and ensuring *everything* works with libav I would not mind at all
> what the default is.

I think this is completely fair! Thanks for that.


> I consider FFmpeg superior, but can understand there are different
> opinions, however, if this is to lower the tree quality

Quality is not a very helpful metric, because it means completely
different things for different people. Some people value code
readability, maintainability, and correctness very high, other people
value having a new idea halfway implemented and released even if it
only kindasorta works and is not at all reliable and not on par with
previous parts of the code.

I see a tendency in myself and in others to not care about what
happens on the inside when thinking merely as a user. I see many many
people complain about the insides when they are not happy with how it
performs. I very rarely see people actually dig in to help fix up the
insides. The same pattern exists in pretty much all projects that I
know of, and it is quite natural - there are more users than
developers.


> then it is obvious libav shouldn't be the default.

It may be obvious to you, but please remember that others may (are
likely to!) have a different metric.


> libav should realize they are the actual fork (this is now pretty
> clear since the takeover failed and ffmpeg didn't collapse...) and
> also rename their libraries so that the internal libav/ffmpeg
> fights would not affect their users anymore and projects could use
> what they think best...

Unless libav considers the API too broken to still be functional I
don't see the point of differentiation. A little bit of competition
can be good overall even though it is more stressful for both sides.
The most important thing is what I asked for already -

That users inform themselves, and make informed decisions.


Anything else is really just an excuse not to have to form, voice,
and defend an opinion - take a stand - which IMO is just as lame as
~10 people who cannot work together.


//Peter

Re: Discussing defaults (Was: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild)

[Alexis Ballier]

On Mon, 11 Feb 2013 17:22:16 +0100
Peter Stuge <peter@stuge.se> wrote:

> Alexis,
> 
> Alexis Ballier wrote:
> > All of this because ~10 people cannot work together, well, really,
> > thank you :)
> 
> Do you have experience from being in a similar situation? You are
> being quite judgemental.
> 
> There are absolutely situations where people so different that
> cooperation simply can't work. It's pretty lame, but unless you
> yourself participate at least on the same level as everyone else
> (on both sides) you really don't get much of a say.

Yes, sorry, I now realize what I wrote is understood differently from
what I meant. I was not criticizing the people, but rather the current
situation. Luca is the one to ask if you want to know more about this,
certainly not me. I am simply a consumer annoyed of having to write
more and more complicated code to support both sides.

I am aware that the split did not come out of nothing, and considering
the vast majority of core FFmpeg developers by that time are now
involved in libav, libav is likely to be the side of 'those who are
right'. However, as I said, maybe with an incorrect tone, I do not
think libav ignoring what happens in ffmpeg to be a pragmatic attitude
and believe it is mainly hurting applications trying to do their
best in supporting both, and users wanting the extra bugfixes or featues
from ffmpeg or the better review process from libav. The critic was
directed towards this, which I believe should be orthogonal to the
reasons of the split.

Finally, I would really love to see some will in reopening the
discussions, be it to merge back (I think that's very unlikely, but
let's not lose hope) or to decide that there is nothing more to be done
and find a sane way out of this lose-lose situation (soname change, or
anything better).

> It's easy to tell people to "stop fighting, just get along" - but
> I believ that intentional fighting is quite rare. It's more likely
> about trying to make one's point.
> 
> That requires communication, but communication is not always
> possible. (I don't mean transmissions back and forth, I mean
> desire to understand the transmissions.)
> 
> For a long time I idealized open source as being an ideal community,
> where communication always worked because everyone wanted it to. But
> that's unfortunately not at all the case.

Yep, thanks for shaking me on this, it seems I should reread twice
before hitting send on an email since I fell in the same trap. Again,
apologies if what I wrote has been taken personally, esp. to those that
tried their best to avoid the split.

[...]
> > I consider FFmpeg superior, but can understand there are different
> > opinions, however, if this is to lower the tree quality
> 
> Quality is not a very helpful metric, because it means completely
> different things for different people. Some people value code
> readability, maintainability, and correctness very high, other people
> value having a new idea halfway implemented and released even if it
> only kindasorta works and is not at all reliable and not on par with
> previous parts of the code.
> 
> I see a tendency in myself and in others to not care about what
> happens on the inside when thinking merely as a user. I see many many
> people complain about the insides when they are not happy with how it
> performs. I very rarely see people actually dig in to help fix up the
> insides. The same pattern exists in pretty much all projects that I
> know of, and it is quite natural - there are more users than
> developers.

Quality here is: Everything that works with FFmpeg works with libav,
and vice-versa. Once that is true, then the default can be what is
deemed better. In this precise case it is controversial, so once
everyone has expressed his arguments and reasons then default should be
what the majority prefers (and here, it seems the majority goes with
libav).

[...]
> > libav should realize they are the actual fork (this is now pretty
> > clear since the takeover failed and ffmpeg didn't collapse...) and
> > also rename their libraries so that the internal libav/ffmpeg
> > fights would not affect their users anymore and projects could use
> > what they think best...
> 
> Unless libav considers the API too broken to still be functional I
> don't see the point of differentiation. A little bit of competition
> can be good overall even though it is more stressful for both sides.
> The most important thing is what I asked for already -
> 
> That users inform themselves, and make informed decisions.

For distributors it does matter: if we start to have libav-only or
ffmpeg-only packages then users get the choice on what package to use,
not the implementation. If there is a differentiation, then upstream
decides what they think is best and that's about it. It would not kill
competition, rather the contrary I believe.

Alexis.

Re: Discussing defaults (Was: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild)

[Peter Stuge]

Alexis - thanks a lot for the awesome response!

Alexis Ballier wrote:
> 'those who are right'

(Just a note that I am in no way invested in libav/ffmpeg, I merely
speak from experience with another fork.)


> However, as I said, maybe with an incorrect tone, I do not think
> libav ignoring what happens in ffmpeg to be a pragmatic attitude
> and believe it is mainly hurting applications trying to do their
> best in supporting both, and users wanting the extra bugfixes or
> featues from ffmpeg or the better review process from libav.

Thanks for clarifying that! And I completely agree with you.
Especially with forks it's important to keep compatibility a
high priority in all projects.


> The critic was directed towards this, which I believe should be
> orthogonal to the reasons of the split.

Yes, I agree also with that. Separate issues.


> Finally, I would really love to see some will in reopening the
> discussions,

I guess it was some years ago, but maybe some more time still is
good. I know no details, I only recognize the pattern.


> > For a long time I idealized open source as being an ideal community,
> > where communication always worked because everyone wanted it to. But
> > that's unfortunately not at all the case.
> 
> Yep, thanks for shaking me on this, it seems I should reread twice
> before hitting send on an email since I fell in the same trap.

It's easy. I did too.


> Again, apologies if what I wrote has been taken personally, esp. to
> those that tried their best to avoid the split.

Not me - but if someone did feel bad about what you wrote I am very
sure that they appreciate this!


> > Quality is not a very helpful metric, because it means completely
> > different things for different people.
> 
> Quality here is: Everything that works with FFmpeg works with libav,
> and vice-versa.

Agree API compatibility is very important.


> (and here, it seems the majority goes with libav)

I for one am sadly uninformed and can not make a decision. :(


> > Unless libav considers the API too broken to still be functional I
> > don't see the point of differentiation.
> 
> For distributors it does matter: if we start to have libav-only or
> ffmpeg-only packages then users get the choice on what package to use,
> not the implementation.

Ah! Yes, but that is just a function of what happens upstream, and
nothing that can ever really be a distribution's job to resolve.

If anything, I think that incompatibilities showing through in the
distribution can only help users become more informed about what
happens upstream.

It can be argued that they shouldn't have to be informed - but
actually I don't mind that. It's good to be aware of what is going
on even a few layers down. I know that this is not a very common
attitude, but I think for Gentoo in particular it wouldn't be bad
at all.


> If there is a differentiation, then upstream decides what they
> think is best and that's about it. It would not kill competition,
> rather the contrary I believe.

You're right that there would possibly be more activity in both
projects if they were going fast in their own direction. On the
other hand that fragments the user base (applications) and everyone
is already invested in the common API, so I can understand that
moving away from that also isn't very desirable.


Anyway - good thoughts. Thanks again!

//Peter

Re: Discussing defaults (Was: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild)

[Luca Barbato]

Your whole email is derailing a bit from discussing the code at hand and
it is going deep down on the people, I'd rather not get there since it
gets totally unrelated the question at hand.

On 11/02/13 14:49, Alexis Ballier wrote:
> All of this because ~10 people cannot work together, well, really, thank
> you :)

May I point you that ~10 people were the majority of what was FFmpeg,
thus 10 people were enough to demote democratically the so called Leader
and that guy got the name from Fabrice as his personal decision?

I'm perfectly happy to develop my code as long I'm not dragged in the
mud with outlandish statement or people annoying the hell of me because
they want to force me to merge because would be so better.

Well, you are talking to one of the two guys that spent about 3 months
behind the scenes trying to compose the situation before it ended with
the in theory normal demotion of a so-called Leader by democratic means.

Sadly or luckily the whole thing ended with us (the majority) having to
give up the name and picking a different one.

Hopefully that's the last time I have to touch this point here.

lu

Re: Discussing defaults (Was: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild)

[Peter Stuge]

Luca Barbato wrote:
> May I point you that ~10 people were the majority of what was FFmpeg,
> thus 10 people were enough to demote democratically the so called Leader
> and that guy got the name from Fabrice as his personal decision?

There was probably a reason for Fabrice to do that, and majority and
democracy doesn't have much to do with it. It is more likely that 10
people are "right" than that 3 are, but a group of 10 is still quite
small. I wouldn't mind reading about the backstory. Do you know of
some good links beyond the two that were posted already?


> I'm perfectly happy to develop my code as long I'm not dragged in the
> mud with outlandish statement or people annoying the hell of me because
> they want to force me to merge because would be so better.

Users will never be satisfied. But I guess you agree that API
compatibility will certainly avoid extra problems for users.


> Well, you are talking to one of the two guys that spent about 3 months
> behind the scenes trying to compose the situation before it ended with
> the in theory normal demotion of a so-called Leader by democratic means.

I don't think open source neccessarily is democracy, and of course a
disagreement about something fairly fundamental such as that can
be more than enough to cause a fork.


> Sadly or luckily the whole thing ended with us (the majority)
> having to give up the name and picking a different one.

I think the name itself doesn't matter much (FWIW I think libav is a
much better name) but API compatibility is a big deal, and all
branches should really make an effort to stay compatible.


//Peter

Re: Discussing defaults (Was: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild)

[Alexis Ballier]

On Mon, 11 Feb 2013 22:04:43 +0100
Luca Barbato <lu_zero@gentoo.org> wrote:

> Your whole email is derailing a bit from discussing the code at hand
> and it is going deep down on the people, I'd rather not get there
> since it gets totally unrelated the question at hand.

I'm not sure if you read my reply, but it was not meant at all as going
down on the people. I realized it was understood as such and
apologized, and apologize again here.

> On 11/02/13 14:49, Alexis Ballier wrote:
> > All of this because ~10 people cannot work together, well, really,
> > thank you :)
> 
> May I point you that ~10 people were the majority of what was FFmpeg,
> thus 10 people were enough to demote democratically the so called
> Leader and that guy got the name from Fabrice as his personal
> decision?
> 
> I'm perfectly happy to develop my code as long I'm not dragged in the
> mud with outlandish statement or people annoying the hell of me
> because they want to force me to merge because would be so better.

It would be better. Nobody wants to force you to do anything though. I
guess that answers my question on a possible reopening of the
discussions.

> Well, you are talking to one of the two guys that spent about 3 months
> behind the scenes trying to compose the situation before it ended with
> the in theory normal demotion of a so-called Leader by democratic
> means.

To be honest, I never understood why this had to be done by a takeover
with such a majority of people, and always wondered why what seen
publicly was only a poor leader asking for democracy but demoted by
force (exagerating a bit). This surely encouraged people to support him.
I guess I should ask you for more details in private.

Alexis.

Re: Discussing defaults (Was: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild)

[Luca Barbato]

On 11/02/13 22:33, Peter Stuge wrote:
> Luca Barbato wrote:
>> May I point you that ~10 people were the majority of what was FFmpeg,
>> thus 10 people were enough to demote democratically the so called Leader
>> and that guy got the name from Fabrice as his personal decision?
> 
> There was probably a reason for Fabrice to do that, and majority and
> democracy doesn't have much to do with it. It is more likely that 10
> people are "right" than that 3 are, but a group of 10 is still quite
> small. I wouldn't mind reading about the backstory. Do you know of
> some good links beyond the two that were posted already?

The reason behind Fabrice actions is probably the same behind me trying
for 3 months to not having to go the way it went. I got to change my
mind since I was involved, Fabrice hadn't been since ages and he is
doing something totally different nowadays.

> Users will never be satisfied. But I guess you agree that API
> compatibility will certainly avoid extra problems for users.

It is not related to users, is related to me being called as swine a
traitor and having death threats. *Slightly* less technical than
discussing API.

> I don't think open source neccessarily is democracy, and of course a
> disagreement about something fairly fundamental such as that can
> be more than enough to cause a fork.

The rules in Libav are quite well defined and decently enforced.

Again, if you have ~15 people and one is deemed misbehaving by more than
10, which is the fork?

lu

Re: Discussing defaults (Was: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild)

[Peter Stuge]

Luca Barbato wrote:
> > Users will never be satisfied. But I guess you agree that API
> > compatibility will certainly avoid extra problems for users.
> 
> It is not related to users,

I was trying to come back on topic. :)


> is related to me being called as swine a traitor and having death
> threats. *Slightly* less technical than discussing API.

That is of course not acceptable under any circumstance. I'm sorry to
hear that you had to deal with that. :(


> > I don't think open source neccessarily is democracy, and of course
> > a disagreement about something fairly fundamental such as that can
> > be more than enough to cause a fork.
> 
> The rules in Libav are quite well defined and decently enforced.
> 
> Again, if you have ~15 people and one is deemed misbehaving by more
> than 10, which is the fork?

The fork is always the younger group, but who is "right" and "wrong"
is another matter.


//Peter

Re: Discussing defaults (Was: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild)

[Ian Whyman]

[-- Attachment #1: Type: text/plain, Size: 230 bytes --]

Guys,

Can we not just have a developer wide vote or something? This instance
clearly not going to resole itself.

Sometimes it seems that endless mailing list threads are the Gentoo way,
its a surprise we get anything done!

Ian

[-- Attachment #2: Type: text/html, Size: 295 bytes --]

Re: Discussing defaults (Was: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild)

[Luca Barbato]

On 12/02/13 08:21, Ian Whyman wrote:
> Guys,
> 
> Can we not just have a developer wide vote or something? This 
> instance clearly not going to resole itself.

It is a little bikeshed. Originally the virtual was ordered in a
way, then ordered in another and now we are discussing which one is
better for the user after we turned it around again.

There isn't ANYTHING that is impacting users beside those that they
might get the next versions of gst-libav just end up with a runtime
error if they use ffmpeg (if the upstream authors follow up with their
plan) or those users wanting to use mencoder might get some compile
errors if I forgot to update the compatibility patch after somebody
bumped w/out testing.

It really boils down to decide to be extra careful with mplayer and xbmc
or being extra careful with gst-libav and maybe vlc.



Sadly this whole discussion turned to discussing who is right or wrong,
who is the fork or not and who's an evil bastard oppressing the poor
Austrian genius or not.

I'm ok discussing technical merits and spend time fixing issues, not so
much discussing stuff I'd rather not discuss such as if I'm an evil
bastard for not working with somebody that joked about my death.


lu

Re: Discussing defaults (Was: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild)

[Rich Freeman]

On Tue, Feb 12, 2013 at 2:21 AM, Ian Whyman <thev00d00@gentoo.org> wrote:
>
> Can we not just have a developer wide vote or something? This instance
> clearly not going to resole itself.

I don't think the average developer is really in a good position to
resolve this - it will just create a whole lot of fuss and who knows
if it will come to the right resolution.  If it really doesn't matter
than save a lot of fuss and flip a coin.

If it does matter then the maintainers of the media-video herd should
resolve this  That's generally where the affected packages are, but
they should of course call for comments from reverse dependencies
after suitably framing the issue.

If anybody feels that isn't going anywhere or isn't going in the right
direction and that something needs to change, they can always ask the
council to take it up.  They're not really the ideal ones to get
involved and will probably want somebody to make a really good case
for why they should step in.  However, if there really is a need for
some kind of democratic vote at least the problem becomes properly
informing seven people and not 200.

Rich

Re: Discussing defaults (Was: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild)

[Alexis Ballier]

On Tue, 12 Feb 2013 12:16:22 +0100
Luca Barbato <lu_zero@gentoo.org> wrote:

> On 12/02/13 08:21, Ian Whyman wrote:
> > Guys,
> > 
> > Can we not just have a developer wide vote or something? This 
> > instance clearly not going to resole itself.
> 
> It is a little bikeshed. Originally the virtual was ordered in a
> way, then ordered in another and now we are discussing which one is
> better for the user after we turned it around again.

That's what he's suggesting to vote about. I consider my concerns
important and, as such, will continue to use FFmpeg but e.g. your
arguments are valid and important too and in the end it boils down to
what one considers more important.
So far I have been the only one voicing against libav being the
default (besides comments on my blog) so I can live with it without
vote since it is clear I am minority. Were there more people favoring
FFmpeg I would say a kind of vote is needed, but so far I don't think
it's worth it.

> There isn't ANYTHING that is impacting users beside those that they
> might get the next versions of gst-libav just end up with a runtime
> error if they use ffmpeg (if the upstream authors follow up with their
> plan) or those users wanting to use mencoder might get some compile
> errors if I forgot to update the compatibility patch after somebody
> bumped w/out testing.

Well, this is important. You, as libav developer, could very well try
to convince gst-libav people that it's stupid to ban FFmpeg for no
technical reason and that the big fat warning when not using the
internal version is more due to historical reasons than anything recent
since all decent distributions do not use their bundled libav version.
mplayer is not that libav-hater as you may think since I believe some
libav-compatibility fixes landed before 1.1 (maybe not all, but at
least the PIX_FMT hell was resolved).

> It really boils down to decide to be extra careful with mplayer and
> xbmc or being extra careful with gst-libav and maybe vlc.

IMHO this has to be done whatever the default is.

> Sadly this whole discussion turned to discussing who is right or
> wrong, who is the fork or not and who's an evil bastard oppressing
> the poor Austrian genius or not.

I didn't want to have it go that way. I was mainly pointing out that,
personal issues apart, FFmpeg has its technical merits that are
completely ignored by libav.

> I'm ok discussing technical merits and spend time fixing issues, not
> so much discussing stuff I'd rather not discuss such as if I'm an evil
> bastard for not working with somebody that joked about my death.

+1

Alexis.