On real hardware:
Attempting to install xbmc results in the following error:
Sorry, the following package cannot be selected:
- xbmc-13.0-1.mga5.i586 (due to unsatisfied libGLEW.so.1.10)
Steps to Reproduce:
The reason for this is that it needs to be rebuilt, but it fails to build. It also needs to be updated, and Buchan did update it to 13.2 in SVN, but it still doesn't build.
xbmc cannot be installed =>
xbmc cannot be installed or built
Adding coling in CC. You have done previous updates for xbmc IIRC colin, maybe something you could help with here. Thanks.
Created attachment 5626 [details]
Failing build log
Here is the log from a recent failed iurt build if it helps anyone to figure it out.
Ahh yeah I've seen this error before. It's to do with using the system groovy rather than a bundled one IIRC.
I think I can coax it into life when I get a moment or three (the groovy stuff confuses the hell out of me!)
Will try and take a look over the weekend.
I do wonder tho', should we consider shipping Kodi instead in MGA5? (rename of XBMC going forward). It's a kinda leaf package so think it should be fine even it we ship a beta or RC - we can update it later to the final. Currently on beta3. WDYT?
(In reply to Colin Guthrie from comment #4)
> I do wonder tho', should we consider shipping Kodi instead in MGA5? (rename
> of XBMC going forward). It's a kinda leaf package so think it should be fine
> even it we ship a beta or RC - we can update it later to the final.
> Currently on beta3. WDYT?
During the weekly QA meeting I agreed that using Kodi rather then
XBMC would be the better move. And we've shipped beta/RC stuff in
the past. This package, IMO, really does not effect anything else
and nothing else is dependent on it.
I think people will look for Kodi now so it makes sense to rename it. It's not beta software but just a name change from xbmc to kodi for trademark purposes. We can add a note to the release notes about it.
We should support them in their choice IMHO.
(In reply to claire robinson from comment #6)
> I think people will look for Kodi now so it makes sense to rename it. It's
> not beta software but just a name change from xbmc to kodi for trademark
Not quite true. It's still xbmc for 13.x, it'll be kodi for 14 onwards and it *is* in beta (currently beta3).
That doesn't stop us renaming the package even if we do stick to version 13 of course, but it is still technically branded as xbmc in that version.
My Bad then. I read about it a few days ago but alot has drifted through my head since then :)
We should still aim for kodi though imho, and be one of the first to ship it.
I agree with going with 14 for 5, will look at it now.
xbmc-13.2 would not build on Cauldron due to Groovy having been compiled against an older (and incompatible) version of objectweb-asm3 back in (IIRC) May.
Since a new Groovy build just made its way into Cauldron, I tried building xbmc-13.2 from the mgarepo SVN again on my system. The build was successful, which means that shipping the officially stable xbmc version is once again an option, if Kodi is not decided upon.
That said, I too agree that shipping Kodi would be better, if at all possible.
(In reply to Anssi Hannula from comment #9)
> I agree with going with 14 for 5, will look at it now.
I have xbmc-13.2-3.mga5 installed from a recent build to test after groovy was updated.
On attempting to update to Kodi there seems to be a strange Obsoletes issue which was discussed last night on dev irc (I noted that you were logged in Anssi).
The error on update is:
1 installation transactions failed
There was a problem during the installation:
file /usr/lib64/xbmc from install of kodi-14.0-0.beta3.1.mga5.x86_64 conflicts with file from package xbmc-13.2-3.mga5.x86_64
file /usr/share/xbmc from install of kodi-14.0-0.beta3.1.mga5.x86_64 conflicts with file from package xbmc-13.2-3.mga5.x86_64
Seems these two files have a #compat comment above them in the %files section.
Yup, mentioned this on the ML too. It's due to rpm not being able to replace a directory with a symlink on upgrade.
Would need to be worked around somehow with %pre doing some rm's (or some nicer trick) for the upgrade case (or just dropping those compat symlinks if they are not strictly needed).
The upgrade issue has been fixed in kodi-14.0-0.beta4.2.mga5.x86_64. Marking as fixed.