[Bug 1030] Review request: xbmc - Media center

[RPM Fusion Bugzilla]

http://bugzilla.rpmfusion.org/show_bug.cgi?id=1030





--- Comment #161 from Alex Lancaster <alexl at users.sourceforge.net>  2010-03-24 19:29:16 ---
OK, back from vacation.  New version (-16) which incorporates Rolf's -15
version, SRPM and RPM are in the process of being uploaded:

* Wed Mar 24 2010 Alex Lancaster <alexlan[AT]fedoraproject org> - 9.11-16
- Add BuildRequires: hdhomerun-devel

* Sun Mar  7 2010 Rolf Fokkens <rolf fokkens[AT]wanadoo nl> - 9.11-15
- Add patch for force using hdhomerun external, had to create a
  hdhomerun-devel package first


Spec: http://alexlan.fedorapeople.org/rpmfusion/xbmc.spec
SRPM: http://alexlan.fedorapeople.org/rpmfusion/xbmc-9.11-16.fc12.src.rpm

x86_64 binary:
http://alexlan.fedorapeople.org/rpmfusion/xbmc-9.11-16.fc12.x86_64.rpm

This allows builds against external hdhomerun (available on F-12 in
updates-testing).  In response the remaining review comments:

(In reply to comment #155)

> * cximage - As this has a separate upstream, I would *really* like to see this
> packaged separately.  However, Alex, if you're willing to commit to trying to
> get this into Fedora after we finish getting XBMC into RPM Fusion, that would
> be good enough for me.

As indicated by upstream in comment #160, looks like cximage will be going away
in new release and would be very difficult to split out as indicated by Ralf,
so should be OK to carry for this release only.

> * libsquish - ditto
> * libhts - ditto
> * libcmyth - if it actually has an active upstream, then ditto

I will commit to looking into these packages if they can be split out
post-review.  I suspect libcmyth is more or less dead upstream, hopefully
upstream XBMC can tell us whether they are now the defacto upstream.

> > I think libGoAhead is the most problematic of them, I will try to remove it in
> > -14.  libhts as noted in reply from upstream in comment #122 is GPLv3+, so
> > should be OK to use with GPLv2+ code if I understand
> > https://fedoraproject.org/wiki/Licensing#GPL_Compatibility_Matrix correctly, it
> > basically means that XBMC is then effectively GPLv3.
> 
> Does that mean we should be changing the listed license to GPLv3+?

I think that the license refers to the source code, not necessarily to
resultant binary.  I think we should probably change the license to: "GPLv2+
and GPLv3+" to indicate that there are sources under both licenses.  If
approved, I will do this immediately before committing.

> > > XBMC stores its language files as xml files.  I'm not sure how that affects this rule.

> Ok, let's consider this unrelated unless someone else tells us something
> different.

OK.

I think this version should hopefully address most, if not all, of the
remaining review concerns.


-- 
Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.