xbmc_12.0~git20121119.22795bc-1_amd64.changes ACCEPTED into experimental

[Andres Mejia]

On Sat, Nov 24, 2012 at 2:09 AM, Reinhard Tartler <siretart at gmail.com> wrote:
> On Fri, Nov 23, 2012 at 8:26 PM, Andres Mejia <amejia004 at gmail.com> wrote:
>> On Thu, Nov 22, 2012 at 1:11 AM, Reinhard Tartler <siretart at gmail.com> wrote:
>>> On Tue, Nov 20, 2012 at 1:12 AM, Andres Mejia <amejia004 at gmail.com> wrote:
>>>> On Mon, Nov 19, 2012 at 7:07 PM, Andres Mejia <amejia004 at gmail.com> wrote:
>>>>> Hi all,
>>>>>
>>>>> FYI, I uploaded a new version of XBMC. I'm notifying you all because
>>>>> of a major change. This version of XBMC will be built and run using
>>>>> XBMC's internal copy of FFMpeg (the 10.2 branch of FFMpeg that is).
>>>>> Due to the number of changes done between FFMpeg and Libav
>>>>> (particularly with libavfilter), it would have taken an enormous
>>>>> amount of work to try and get XBMC building and running using Libav.
>>>>> Also, I did forget to note this major change in the changelog, but I
>>>>> did add a NEWS entry for this. Sorry about that.
>>>>>
>>>>> Also as an aside, I think we should discuss how to get ffmpeg back
>>>>> into Debian again. As I said some time ago, either Libav, FFMpeg, or
>>>>> both have to get their libraries and header paths renamed.
>>>>
>>>> I also want to note this now, apparently chromium has been using it's
>>>> own internal copy of FFMpeg for some time now. Therefore, XBMC is not
>>>> the first package where using an internal ffmpeg is being done.
>>>>
>>>
>>> Are you sure that all involved developers, including chromium & xbmc
>>> upstream as well as their packagers, would agree on the same FFmpeg
>>> snapshot?
>>
>> I don't believe anyone ever mentioned that these two projects should
>> use the same snapshot of ffmpeg.
>
> Well, it is out of question that having many different versions of a
> library such as libavcodec is not acceptable for a stable Debian
> release.
>
> FYI, I've asked on IRC the release team and the security team about
> that. The security team referred to the security team, who respond
> with:
>
> 23:47 <gilbert_> siretart: iuculano made the switch to embedded
>                  libav.  his plan is to bump chromium to each new
>                  upstream throughout wheezy's support lifetime, and
>                  having the embedded library makes that a lot more
>                  feasible.  my opinion is to not release chromium in
>                  stable at all since even that is going to way too
>                  much work, but i've been overrulled.  seems people
>                  actually want chromium in stable...
>
> Chromium is not a good precedent at all. The maintainer has even
> joined the security team for having and maintaining it in stable.
> Moreover, you have to keep in mind that most security issues and fixes
> do come from chromium upstream. Therefore, this is hardly an excuse
> for xbmc for handling and outdated, internal copy of FFmpeg in a
> distribution package.
>
>>
>>> TBH, I'm very skeptical. And with FFmpeg releasing like crazy after
>>> the fork, I don't see the project suitable at all for a distro
>>> scenario such as Debian. For instance, you indicate that XBMC uses the
>>> 0.10 branch; the latest upstream release, however, is 1.0, the release
>>> before is 0.11. Chromium maintains it (defacto) own branch, which
>>> admittedly is based on FFmpeg master. Therefore, tracking upstream
>>> releases does not seem to accommodate either project.
>>>
>>> To conclude, I understand that xbmc is causing new challenges here,
>>> but TBH, I think the better solution would be to investigate what's
>>> missing in libav's libavfilter. For instance, I think you mean the
>>> audio filter still, which has landed in libav 9. I imagine that there
>>> is still some stuff missing, but if it is useful, I'm sure it can be
>>> submitted libav upstream.
>>>
>>> --
>>> regards,
>>>     Reinhard
>>
>> I don't work on the components of xbmc that uses ffmpeg. Elupus is who
>> you want to speak to. You can either try the xbmc-dev channels or the
>> xbmc forums to reach out to him to see what (if anything) libav could
>> do so xbmc could work with libav.
>
> Sorry, I definitely do not have the resources to engage with xbmc, at
> least not at this point, as I am more than busy with preparing stable
> libav releases and getting the libav 9 transition going in ubuntu,
> here is the current progress:
> https://launchpad.net/~motumedia/+archive/libav9-raring/+packages
>
> Help would be more than welcome.
>
> To conclude, the fact that the xbmc source package bundles FFmpeg is
> an RC bug to me that hinders its acceptance jessie. This means that I
> have no problems having such a copy in experimental, or even unstable,
> but just not in testing.
>
> BTW, we have a similar problem with mplayer, were I have the very same opinion.
>
> --
> regards,
>     Reinhard

I think you meant to respond in the mailing lists. Thanks for your input.

-- 
~ Andres