2013/6/26 Xavier Bachelot <xavier(a)bachelot.org>
>> (d) Move the whole thing (back) to RPM Fusion (where it originally was,
>> we started needing xine-lib for Amarok and Phonon, which both no
>> use it). It would go to the Free section, of course.
>> My proposal is to go with (d).
>> The following packages currently depend on xine-lib:
>> * gxine
>> * (k9copy – already in RPM Fusion, not affected)
>> * kaffeine (my package, the reason why I maintain xine-lib in the first
>> * oxine
>> * xine-plugin
>> * xine-ui
>> These packages would have to move to RPM Fusion along with xine-lib.
>> In Kaffeine's case, upstream is switching from xine-lib to MPlayer in
>> repository, so it will likely have to move to RPM Fusion sooner or later
>> anyway. This means the affected packages are basically *xine*.
>> So my plan is to retire (for my packages, resp. have the respective
>> retire) the listed packages in Fedora for Fedora ≥ 17 and get (or have
>> respective maintainer get) them into RPM Fusion Free instead. (I'd take
>> of xine-lib and kaffeine myself, I hope the maintainers of the other
>> will take care of them.)
> Sounds good, I say go for it!
It's probably a bit late for F17, as F19 is almost out the door (!), but I
have a specfile merging and cleaning the bits from Fedora and RPM Fusion
xine-lib 1.2.3. It's also adding support for VAAPI and VDPAU. 2 patches to
building VAAPI got pushed upstream along the way.
I'm attaching a preliminary version to this mail. It still need a bit of
cleaning though. Given the changes involved, I think it might be a good
I would like a update bug open on our bugzilla about this (if not done
I would like a preliminary agreement that the fedora package will be
Specially as not alll possibilities might be done in order for xine-lib to
stay in fedora. (such as bundling a special version of libavformat or else
in xine-lib fedora, as soon as it's not libavcodec)