Bug 14407 - xbmc cannot be installed or built
Summary: xbmc cannot be installed or built
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: i586 Linux
Priority: Normal normal
Target Milestone: ---
Assignee: Anssi Hannula
QA Contact:
URL:
Whiteboard: 5beta1
Keywords: Triaged
Depends on:
Blocks:
 
Reported: 2014-10-29 00:30 CET by William Kenney
Modified: 2014-11-25 19:00 CET (History)
5 users (show)

See Also:
Source RPM: xbmc-13.0-1.mga5.i586
CVE:
Status comment:


Attachments
Failing build log (56.75 KB, text/plain)
2014-11-21 00:24 CET, Barry Jackson
Details

Description William Kenney 2014-10-29 00:30:11 CET
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)

Reproducible: 

Steps to Reproduce:
William Kenney 2014-10-29 00:30:37 CET

Whiteboard: (none) => 5beta1

Manuel Hiebel 2014-10-29 08:41:34 CET

Keywords: (none) => Triaged
Assignee: bugsquad => anssi.hannula

Comment 1 David Walser 2014-10-29 22:01:24 CET
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.

CC: (none) => bgmilne
Summary: xbmc cannot be installed => xbmc cannot be installed or built

Comment 2 claire robinson 2014-11-20 21:52:55 CET
Adding coling in CC. You have done previous updates for xbmc IIRC colin, maybe something you could help with here. Thanks.

CC: (none) => eeeemail, mageia

Comment 3 Barry Jackson 2014-11-21 00:24:57 CET
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.

CC: (none) => zen25000

Comment 4 Colin Guthrie 2014-11-21 16:22:00 CET
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?
Comment 5 William Kenney 2014-11-21 16:27:12 CET
(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.

Thanks Colin.
Comment 6 claire robinson 2014-11-21 17:45:21 CET
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.
Comment 7 Colin Guthrie 2014-11-21 17:52:02 CET
(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
> purposes.

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.
Comment 8 claire robinson 2014-11-21 18:16:05 CET
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.
Comment 9 Anssi Hannula 2014-11-21 18:25:07 CET
I agree with going with 14 for 5, will look at it now.

Status: NEW => ASSIGNED

Comment 10 Theodoros Kalamatianos 2014-11-23 14:33:49 CET
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.

CC: (none) => thkala

Comment 11 Barry Jackson 2014-11-25 11:50:52 CET
(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.
Comment 12 Colin Guthrie 2014-11-25 12:47:45 CET
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).
Comment 13 Anssi Hannula 2014-11-25 19:00:23 CET
The upgrade issue has been fixed in kodi-14.0-0.beta4.2.mga5.x86_64. Marking as fixed.

Status: ASSIGNED => RESOLVED
Resolution: (none) => FIXED


Note You need to log in before you can comment on or make changes to this bug.