Summary: | sys-apps/i2c-tools appears not to build py-smbus | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | lxg <mail2lx> |
Component: | New packages | Assignee: | Mobile Herd (OBSOLETE) <mobile+disabled> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | Ebuild for a standalone py-smbus |
Description
lxg
2008-11-09 17:09:24 UTC
Addendum: It appears the the module smbus actually could be build from the contents of the i2c-tools package: When emerging i2c-tools and pressing Ctrl+C before the installation, you will find a directory /var/tmp/portage/sys-apps/i2c-tools-3.0.1/work/i2c-tools-3.0.1/py-smbus with a setup.py. This script is to compile the file smbusmodule.c. However, a "python setup.py install" will fail due to missing definitions. It appears that smbusmodule.c lacks an include for linux/i2c.h (it only includes linux/i2c.h). After adding the include, the compile runs fine and the python module is installed. However, it still appears to be broken: # python -c "import smbus" Traceback (most recent call last): File "<string>", line 1, in <module> ImportError: /usr/lib/python2.5/site-packages/smbus.so: undefined symbol: i2c_smbus_process_call Now I'm trying to find out what/where i2c_smbus_process_call could be. Sorry, in my last comment, it should say: "... (it only includes linux/i2c-dev.h)". There is a python-smbus package for Ubuntu Hardy: http://packages.ubuntu.com/de/hardy/i386/python-smbus/download Copying the smbus.so and smbus-1.1-py2.5.egg-info from that Debian archive appears to work. At least 'python -c "import smbus"' does not fail anymore. Created attachment 178476 [details]
Ebuild for a standalone py-smbus
Ok, I finally found a fix for the problem; it is two-fold:
1. The i2c-tools ebuild should explicitely build the py-smbus module, which it currently doesn't.
2. There's a bug in the i2c-tools package's py-smbus/smbusmodule.c: Instead of including its own i2c-dev.h, it includes the kernel's one.
I've implemented the fix as an ebuild, because I need only py-smbus to work and I didn't want to mess around with a local ebuild of i2c-tools. Also, i2c-tools/lm_sensors are AFAIK only build dependencies for the py-smbus module, so I think it could as well be standalone in Portage.
The ebuild is attached, it also contains a patch for smbusmodule.c. Feel free to loot the ebuild and merge it into sys-apps/i2c-tools -- or to introduce a new ebuild for py-smbus.
By the way, why is >lm_sensors-3 still masked in Portage? And wouldn't it be possible to have i2c-tools not depend mandatorily on lm_sensors (Maybe a switch with a USE flag)? At least, there must have been a purpose in dividing both packages with v3.
i2c-tools-3.0.2 should work with USE=python Thanks for the the version bump and applying the fix. I just synced, updated i2c-tools and tried -- works like a charm. And please ignore my statement about i2c-tools depending on >lm_sensors-3. I must have confused that when first investigated the issues with i2c-tools and since then had it in mind. But I just unmerged lm_sensors completely, and when trying to re-emerge i2c-tools, it doesn't require lm_sensors. |