Created attachment 285843 [details] files/linux3.patch Upstream bug: http://code.google.com/p/pybluez/issues/detail?id=48 Symptom: >>> import bluetooth Traceback (most recent call last): File "<input>", line 1, in <module> File "/usr/lib64/python2.7/site-packages/bluetooth/__init__.py", line 49, in <mo dule> """ NameError: name 'discover_devices' is not defined Problem is a bit weird to track down, as it depends on whether you have *built* your cpython runtime under a linux-2.6 or a linux-3.x kernel (and the NameError exception is not really helpful).
Created attachment 285845 [details, diff] Patch to pybluez-0.18.ebuild
Upstream merged this patch, but it's only in SVN. I'm not expecting a release with this patch in it soon (Last release was in 2009). Waiting for an upstream release will mean more and more gentoo users will start to have problems related to this package - that is, when *(kernel)-sources-3.x.x is stabled and the user rebuilds python. These problems can be preempted, saving valuable dev time and keeping users happy. I very strongly suggest this patch and ebuild be put in the portage tree as a -r1. After all, upstream has merged my patch so it can't be THAT bad now can it ;-) Can we at least change the status to CONFIRMED, so it will get some more eyeballs? I mean, there's an upstream bug for it and the upstream dev has merged the patch which kinda means it has already received authoritative acknowledgement. No need to hang around and wait for the hard to debug breakage which is bound to take place, let's be proactive and preempt!
Can you post a link to the resulting changeset in the upstream repo?
Certainly. http://code.google.com/p/pybluez/source/detail?r=54
Why is 3.0.6 stable but this bug is not fixed? As far as I can see, there are two solutions: Let pybluez-0.18 depend on kernel < 3 or backport the upstream fix. I tested the attached fix for some time now and it is working well. Thanks.
Does this problem occur with the newest versions of dev-lang/python?
> Does this problem occur with the newest versions of dev-lang/python? I suppose not. 'linux2.patch' (in python-2.7.2-r3.ebuild and python-3.1.4-r3.ebuild), based on changeset http://hg.python.org/cpython/rev/c816479f6aaf/ , sets sys.platform to 'linux2' even when compiling cpython under linux3. There's a lengthy discussion on this decision here: http://bugs.python.org/issue12326 (Arfrever, you're on the nosy list so this ain't news for you I guess) So for now this seems to have been solved, but expect packages to break in in similar manners in python 3.3 because sys.platform will be 'linux' from then on. Tested on my python-2.7.2-r3, compiled under linux3: python -c 'import sys; print(sys.platform)' now says linux2 instead of linux3 as it did with python-2.7.1-r1 .
(In reply to comment #6) > Does this problem occur with the newest versions of dev-lang/python? Ok, I compiled the pybluez version from portage again. It works for now with python-2.7.2-r3. In this case my point (that the kernel3.0.6 is stable) is very weak. But the fix in python is just a workaround. The real bug is here, in pybluez.
The patch has been committed to upstream trunk. Python 3.3 will break stuff again. The only way pybluez will break in the future is if its py3k release (which does not exist yet) would *not* incorporate the patch which is now in pybluez trunk. That is an unlikely scenario. So I guess that sometimes, indeed, problems will go away if you wait long enough. In this case it was upstream cpython that 'fixed' this (well they didn't really, they just decided to postpone breakage until python 3.3). I'm marking this as RESOLVED UPSTREAM .
