http://bugzilla.rpmfusion.org/show_bug.cgi?id=1030
--- Comment #47 from [email protected] 2010-01-21 11:04:19 --- (In reply to comment #46) > (In reply to comment #45) > > (In reply to comment #42) > > > > > > > I added next 3 patches to trac: http://xbmc.org/trac/ticket/8590 > > Thanks. > > > > > Patch8: xbmc-9.11-spyce.diff > > This fixes python-2.6 syntax errors (the syntax of the sources xbmc has > > merged > > into their source-tree is invalid) > > OK, is it fixed in trunk? Last time I checked, it wasn't fixed - IIRC, it had been reported before and similar patches be proposed before. However, spyce, as many other parts in xbmc, actually is a standalone project with a (seemingly dead) upstream of its own (http://spyce.sourceforge.net). > There are plans to move to libprojectM 2.0.1 in trunk, I think, but I don't > think they have as yet: > > http://xbmc.org/trac/ticket/8277 > > and ultimately we should be compiling against the external version: Yep. I already had considered to propose a projectM1/compat-projectM1 package in fedora, but abandoned this plan ;) > http://xbmc.org/trac/ticket/8408 > > so is it still worth submitting this patch upstream?? I don't know - If can easily be realized, then why not, if not ... no biggy, IMO. > > > Patch11: xbmc-9.11-changeset-26191.diff > > OK, but the next 10.x version will presumably be from trunk, so I don't know > if > there is a point in resubmitting it as a trac ticket upstream, they'd probably > just close as being fixed in trunk. I don't think xbmc upstream make point > releases based on the branches AFAIK, except for the "Live" version, and in > this case, we are effectively "Live" Well, ... I think xbmc needs to reconsider their release procedures, but provided what I am observing in trunk, I would expect the worst (e.g. AFAICT, they recently added mingw32 binaries, ...) > > > This fixes problems with web server segfaulting on x86_64, I submitted > > > http://xbmc.org/trac/ticket/8591 > > > Patch12: xbmc-9.11-GoAhead.diff > > This was submitted and they immediately closed it, Ah, OK ... > apparently goahead is about > to be replaced: http://xbmc.org/trac/ticket/8591#comment:1 Ah, ... I noticed somebody recently pointed out to upstream xbmc that GoAhead's license is quite problematic ... > Perhaps you could just make the modifications relative to my last (-8) spec > file, update the changelog and then attach it (and any new patches) right to > this bug. That's what I am already trying ... but working on this package in my spare time, I resync'ing occassionally is tedious. > Also: are you willing to actually review this? Yes, I would, ... but we aren't there yet. Current showstopper: RPM_OPT_FLAGS (This one topic, I am trying to address. So far I've caught much of it, but not yet all - It is the patch which collides with your patches :) ). Also: Has anybody tried to build this beast on ppc-*'s? I would not expect it to build at all. > Or is there somebody who is, > since nobody has yet volunteered. I intentionally did not assign this BZ to me to leave room to others to step in. -- 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.
