[Bug 1030] Review request: xbmc - Media center
http://bugzilla.rpmfusion.org/show_bug.cgi?id=1030
--- Comment #161 from Alex Lancaster <alexl(a)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.