From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id E151F1384F0 for ; Wed, 16 Jan 2013 21:52:56 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6774821C144; Wed, 16 Jan 2013 21:52:45 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 5AFED21C13C for ; Wed, 16 Jan 2013 21:52:39 +0000 (UTC) Received: from [192.168.0.93] (dynamic-adsl-84-220-165-116.clienti.tiscali.it [84.220.165.116]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: lu_zero) by smtp.gentoo.org (Postfix) with ESMTPSA id 0DC2A33BEC9 for ; Wed, 16 Jan 2013 21:52:37 +0000 (UTC) Message-ID: <50F72134.6090900@gentoo.org> Date: Wed, 16 Jan 2013 22:52:52 +0100 From: Luca Barbato User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild References: <20130116124002.B9FA22171D@flycatcher.gentoo.org> <20130116170907.6ee31e7d@gentoo.org> <50F70FE8.6000507@gentoo.org> <20130116183110.403ea209@gentoo.org> In-Reply-To: <20130116183110.403ea209@gentoo.org> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Archives-Salt: c1b77299-c47d-4a80-8c96-42c686c91c34 X-Archives-Hash: e3ea8e9fc2299c46764adf461af52cb6 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