[ubuntu/precise] xine-lib 1.1.19-3.1ubuntu1 (Accepted)

[Reinhard Tartler]

On So, Okt 30, 2011 at 23:28:20 (CET), Micah Gersten wrote:

> On 10/30/2011 05:49 PM, Micah Gersten wrote:
>> On 10/30/2011 05:35 PM, Reinhard Tartler wrote:
>>> xine-lib (1.1.19-3.1ubuntu1) precise; urgency=low
>>>
>>>   * merge from debian, remaining changes:
>>>     - Because the following libraries are only in universe,
>>>       build against internal copies of:
>>>       - libdvdnav, libdvdread, libfaad, libvcdinfo-dev
>>>     - change order of the alternate dependencies libxine-plugins and
>>>       libxine1-misc-plugins. The former would drag in libxine1-ffmpeg
>>>       via recommends on the live cd.
>>>   * reenable xineplug_decode_image.so
>>>     - use libmagickwand-dev instead of graphicsmagick-libmagick-dev-compat
>>>       as the former is found in ubuntu/main.
>>>
>>> xine-lib (1.1.19-3.1) unstable; urgency=low
>>>
>>>   * Non-maintainer upload.
>>>   * Add patch from Reinhard Tartler to fix FTBFS with libav 0.7.  Closes:
>>>     #628197.
>>>   * Add patch from Loic Dachary to remove pvr from the plugins now that v4l
>>>     is gone. Enable v4l on linux instead of on !linux.  Closes: #623595.
>>>
>>> xine-lib (1.1.19-3) unstable; urgency=low
>>>
>>>   * add missing #include<X11/extensions/XvMClib.h> to avoid FTBFS,
>>>     Closes: #610635
>>>
>>> Date: Sat, 29 Oct 2011 18:58:50 +0200
>>> Changed-By: Reinhard Tartler <siretart at tauware.de>
>>> Maintainer: Ubuntu Core Developers <ubuntu-devel-discuss at lists.ubuntu.com>
>>> https://launchpad.net/ubuntu/precise/+source/xine-lib/1.1.19-3.1ubuntu1
>>>
>>
>> This is troubling, here's the last merge changelog entry:
>> xine-lib (1.1.19-2ubuntu1) natty; urgency=low
>>
>>   * merge from debian, remaining changes:
>>     - remove build-dependency on libvcdinfo-dev, fixes FTBFS.
>>     - don't build against system libdvdnav, libdvdread, both in universe
>>     - build the faad plugin against the internal copy of libfaad
>>     - change order of the alternate dependencies libxine-plugins and
>>       libxine1-misc-plugins. The former would drag in libxine1-ffmpeg
>>       via recommends on the live cd.
>>   * remove graphicsmagick-libmagick-dev-compat, not in main
>>
>>
>> Before, we were only using one internal library and building one
>> plugin from it.  Now we're building against 4 internal libraries. 
>> This doesn't seem like a good idea for the LTS as the security team
>> will most likely have to support those embedded libraries for 5
>> years.  Is there a need for this change?  Also, the only rdepends of
>> xine-lib in main are kaffeine and kde-runtime.
>> @kubuntu-devel
>> Do we need this other functionality?  If so, can we please get MIRs
>> for those libraries?
>>
>> Thanks,
>> Micah
>>
> I have to apologize.  As Colin pointed out to me in #ubuntu-devel,
> nothing has actually changes between the natty and precise packages in
> terms of the diff from Debian (i.e. changing which internal libraries
> are built against).

06:58 <siretart> cjwatson: yeah, this time, I took some extra time for
                 the merge, in total two evenings. My goal was to
                 minimize the diff as well as possible and clarify the
                 current situation as good as possible
06:58 <siretart> cjwatson: and you are totally right, the previous merge
                 changelog was done rather in a hurry, and nothing
                 really has changed wrt system/internal library copies

> So, thank you Reinhard for making the current state
> clearer in the changelog :).

You're welcome!

> However, these should still probably be examined for the LTS if we
> should be using these internal libs, MIR them, or possibly drop them
> from the package.

We are talking about these source packages:

- vcdimager
- libdvdnav
- libdvdread
- libfaad

and possibly graphicsmagick for graphicsmagick-libmagick-dev-compat.

TBH, I don't believe that we manage to promote all of these to main in
one cycle, unless we have other packages that would benefit from these
as well (gstreamer?).

What I'd propose to investigate to see if we could possibly demote
xine-lib to universe. Currently, as far as I read the germinate output,
the 'only' packages that drag in xine-lib are the source packages
'kde-runtime', 'kaffeine', which build-depend on 'libxine1-dev'.

As the kubuntu team is already copied with this e-mail thread, I'd be
interested in hearing your opinions on xine. In my book, xine has almost
stalled¹ development wise upstream, is defacto orphaned² in debian, and
doesn't receive nearly the attention in ubuntu that it would
require³. Therefore, I'm wondering if it wouldn't be a worthwhile goal
to either not ship it in main for the next LTS, or to decide to
*considerably* invest kubuntu-devel resources in getting xine-lib into
reasonably good shape.

Perhaps you could schedule a session at UDS-P for that? If you do,
please try to catch me on irc about when, maybe I can participate via
voip or something.

Cheers,
Reinhard

Footnotes:
1: The last upstream release was 1.1.19, the debian package contains a
number of upstream cherry-picks, but the remaining upstream devs
'preserve' the current state for the 1.1 branch. New developments are
scheduled for 1.2, but that branch is still not closed for ABI/API
changes, without realistic release date. Which is kinda hard to target
if there is only one or two upstream devs with little time left. Sad but
true.

2: While I'm listed in xine-lib's uploader field, Darren's (the 'main'
debian maintainer and the upstream guy that does releases) choice for
mercurial has made it defacto impossible for me to contribute. I'm
currently considering either asking Darren to remove me from that field
(which I find unlikely that he will do, as he didn't even react to the
last NMU), or to hijack the package and maintain it under the
pkg-multimedia umbrella. I'm quite undecided what to do here.

3: https://launchpad.net/ubuntu/+source/xine-lib/+bugs lists a lot of
bugs, many of them crashers and quite old. TBH, I find the number of
bugs surprisingly low given the lack of activity in terms of bug
triaging/work/management.  But OTOH, maybe that also indicates that our
users mostly avoid xine in favor of mplayer, mplayer2 or vlc.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4