On 02/23/2010 10:54 PM, Nicolas Chauvet wrote:
2010/2/23 David Timms<dtimms(a)iinet.net.au>
> On 24/02/10 07:27, RPM Fusion Bugzilla wrote:
>
>>
http://bugzilla.rpmfusion.org/show_bug.cgi?id=1030
>>
>> --- Comment #100 from Alex Lancaster<alexl(a)users.sourceforge.net>
>> Yep: -12 is the most recent.
>>
>
> Hi, I would like to suggest that this package review (which has really been
> more of a packaging development bug) be closed, and a new one requested.
> (close duplicate after create new bug)
>
> This would keep the normal review stuff together, and uncluttered by the
> preliminary package development work.
>
> Anyone else agree/disagree ?
>
> Cheers,
> David Timms.
>
I don't see any problem with keeping the same bug report for the review,
Agreed. IMO, it's simply a case of a "complicated review".
That development side was fully part of the review process.
I don't see any reason to split, specially as this review seems exemplary of
what work need to be achieved if a package doesn't comply with our
guidelines.
Once that said, I guess a sum-up of what remain to be worked on, would be
welcome for a new comer.
OK, an attempt of a short summary:
* Technically: *-12 doesn't build for FC13 ;)
- An API change between rpmfusion's FC12 and FC13's ffmpeg breaks xbmc.
- xbmc is victim of the DSO changes in FC13.
- There is a subtile configure script bug somewhere causing it to
(silently) not to work for FC13.
I have dirty hacks addressing the 1st and 2nd issues pending, but am
still investigating the latter, yet. Could be one these "autoreconf is
harmful" cases, could also be a side-effect of the DSO-changes, could be
something else, ... I don't know yet.
* Usability-wise:
- Verify that python works sufficiently.
There have been reports that xbmc's python scripts (python2.4) don't
work on Fedora (python2.6). I haven't see any such python breakdown yet,
so I don't know how to reproduce such breakdown.
- Decide about what to do with xbmc-standalone.
IMO, it's dysfunctional.
- Decide about what to do with /usr/bin/xbmc's "core dump feature".
To me, it's nothing but silly.
* Perform a legal review.
- AFAICT, even if putting patent issues aside, xbmc is not [L]GPL'ed,
because it contains subpackages/libraries which are not
[L]GPL-compatible. The original xbmc code certainly is "free", but I am
having strong doubts if all of the libraries they have bundled, are
(e.g. GoAHead, UnRar).
In Fedora, I would reject this package for "improper licensing" and/or
delegate it for legal review to FE-LEGAL. No idea, about what rpmfusion
wants to do about it.
- One detail: xbmc contains fonts, which suspiciously look like "bundled
msttcorefonts", but I haven't checked the details, yet.
* Packaging-wise/FPG-compliance-wise: xbmc contains many "bundled"
libraries.
Alex, Rolf and I already removed some of them, but one would have to
check further of them can be replaced with "unbundled" versions and
which of them can't because upstream xbmc has hacked them up.
Ralf