Bug 1575

thanks for the bug.  I had noticed this problem before, but somehow thought that it had been fixed sometime in the various dharma pre-releases. But it looks like I had fixed it locally but forgotten about it.  Would it be sufficient to apply you patch on http://trac.xbmc.org/ticket/9818  or does it also require adding the make and make install within the rpm spec file as well?  if so, could you provide me the commands that work for you and I'll add to the %build section in the spec file respin a new version.  Incidentally latest specs can be found here:

http://cvs.rpmfusion.org/viewvc/rpms/xbmc/devel/?root=free

also my development version (which I periodically sync with the rpmfusion cvs) is here in git:

http://fedorapeople.org/gitweb?p=alexlan/public_git/xbmc-rpm.git;a=tree

(In reply to comment #0)
> XBMC includes (sort-of) two Python modules that are not built and installed by
> default; PIL and sqlite. Some information in this thread:
> 
> http://forum.xbmc.org/showthread.php?t=77708
> 
> I noticed that the package is build with --enable-external-python. Should it be
> grabbing these modules from the system? If so, something is broken. If not,
> then these two modules need to be handled as some addons require them.


Yes it ideally should be using the system versions, but I think it still needs some xbmc wrappers to be compiled even in the case of external version of python, but not sure. 

The problem in ticket #9818 is solved as far as I can tell.

As for a fix, the quick-and-dirty is to package PIL and PySQLite in this package as well, fudge the Makefiles a bit and just run make in those directories as part of the build. That's easy enough, but shipping extra versions of these modules seems like a bad idea.

A better fix would be to point xbmc at the system versions. If I'm understanding things correctly, we are using the system python interpreter and should therefore have no problem using modules compiled for it. The question is just how to point xbmc at them. Why isn't the standard site-packages used and can we activate it?

Had another look at it and xbmc does some attempt at preserving Python include paths. Somehow the site-packages ones get lost though. Relevant file is XBPyThread.cpp if you want to go digging...

I also noticed though that the addon directories for PIL and PySQLite are created. So it was just a matter of symlinking from those to the system implementations. This patch fixes the issue:

--- xbmc.spec.orig	2010-12-29 13:38:18.883478940 +0100
+++ xbmc.spec	2010-12-29 13:25:00.889813348 +0100
@@ -138,6 +138,10 @@
 Requires: librtmp
 Requires: libbluray
 
+# And these are just symlinked to
+Requires: python-imaging
+Requires: python-sqlite2
+
 %description
 XBMC media center is a free cross-platform media-player jukebox and
 entertainment hub.  XBMC can play a spectrum of of multimedia formats,
@@ -199,6 +203,13 @@
  --dir=${RPM_BUILD_ROOT}%{_datadir}/applications \
  $RPM_BUILD_ROOT%{_datadir}/applications/xbmc.desktop
 
+# Normally we are expected to build these manually. But since we are using
+# the system Python interpreter, we also want to use the system libraries
+ln -s %{python_sitearch}/PIL \
+ $RPM_BUILD_ROOT%{_libdir}/xbmc/addons/script.module.pil/lib/PIL
+ln -s %{python_sitearch}/pysqlite2 \
+ $RPM_BUILD_ROOT%{_libdir}/xbmc/addons/script.module.pysqlite/lib/pysqlite2
+
 %clean
 rm -rf $RPM_BUILD_ROOT

Hi,

I agree with Pierre Ossman's last comment. XBMC provides SQLite support not via system libraries, but via an add-on (which means you can have SQLite support inside XBMC while not having it outside it and vice versa). The add-on is "script.module.psqlite" and it will be great to have it on the RPMFusion build, because: 

- It is by default available on Ubuntu PPA (where the XBMC is primarily developed and which is used as reference implementation for testing any problems or new features);

- Since SQLite is available on Ubuntu PPA version of XBMC, developers tend to assume it is always available; any add-on that does not check for the presence of SQLite support when it is absent will miserably fail (e.g., install the iPhoto add-on on the RPMFusion version and try to run it). I develop an XBMC add-on (Icecast) which does check for SQLite availability and if absent, uses a text-only backend, but this only happens because my primary development platform is Fedora.

If I can help with further testing or building, please, let me know.

WWell,

(In reply to comment #5)
> Hi,
> 
> I agree with Pierre Ossman's last comment. XBMC provides SQLite support not via
> system libraries, but via an add-on (which means you can have SQLite support
> inside XBMC while not having it outside it and vice versa). The add-on is
> "script.module.psqlite" and it will be great to have it on the RPMFusion build,

> 
> If I can help with further testing or building, please, let me know.

Patches that enable the use of the system sqlite lite from XBMC welcome.  (Using bundled versions is the option of last resort see: https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries )

The patch above is insufficient? :)

(In reply to comment #7)
> The patch above is insufficient? :)

sorry, didn't look at it closely, I thought that was the patch that you had posted on xbmc trac.  I'll look into applying it and respinning a new version.

New version: 10.1 is on the way (currently building f15, then once that completes, will do f14 and f13 builds), I've incorporated this patch, please test once they appear in rpmfusion-free-updates-testing (or you can download from http://buildsys.rpmfusion.org/plague-results/ ).

No dice. You've managed to get a weird dependency on that package:

	libjpeg.so.62(LIBJPEG_6.2)(64bit) is needed by xbmc-10.1-1.fc14.x86_64

And that isn't provided by Fedora's libjpeg-turbo. The key issue is the symbol versioning "LIBJPEG_6.2", which isn't present in Fedora's build of libjpeg-turbo. Not sure what devel libraries were used by the rpmfusion build system.

Ah, yes. I just remembered that this versioning was added in libjpeg-turbo 1.1.0. That version is in Fedora's updates-testing, but not updates. It seems rpmfusion is using those packages as a build source. Probably not a good idea as you never know when they'll end up in the Fedora updates...

Anyhoo, if you enable updates-testing as well then things install.

The AMT plugin seems to work, so this specific bug seems to be solved. Thanks. :)

(In reply to comment #11)
> Ah, yes. I just remembered that this versioning was added in libjpeg-turbo
> 1.1.0. That version is in Fedora's updates-testing, but not updates. It seems
> rpmfusion is using those packages as a build source. Probably not a good idea
> as you never know when they'll end up in the Fedora updates...

Well, I think that's how rpmfusion does it's builds, by building against updates-testing from Fedora by default.  The idea is that by the time that packages go from rpmfusion-free-updates-testing to rpmfusion-free-updates, that the corresponding packages in updates-testing from Fedora will go to updates (stable).  

> Anyhoo, if you enable updates-testing as well then things install.


Timing of these pushes is a problem in general because Fedora packages built at the same time may be pushed asynchronously to updates because of bodhi, but rpmfusion packages built at around the same time get pushed synchronously to stable because there's currently no equivalent to bohdi and packages get pushed on an ad-hoc basis.   In those cases that lead to broken deps (e.g. if dep in Fedora gets pushed before the rebuilt rpmfusion dependent package), generally an individual package can be pushed manually at request.  

(In reply to comment #12)
> The AMT plugin seems to work, so this specific bug seems to be solved. Thanks.
> :)

Thanks.  I'll probably wait until this package is pushed to f14 and f13 stable, before closing.

Hi,

Got it finally on F14 32-bit yesterday; works fine.

WWell,

(In reply to comment #15)
> Hi,
> 
> Got it finally on F14 32-bit yesterday; works fine.

Thanks.  Closing.