After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 674414 - Cannot link Galaxy S II to computer with gnome-bluetooth 3.4.0
Cannot link Galaxy S II to computer with gnome-bluetooth 3.4.0
Status: RESOLVED FIXED
Product: gnome-bluetooth
Classification: Core
Component: applet
3.4.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-bluetooth-general-maint@gnome.bugs
gnome-bluetooth-general-maint@gnome.bugs
Depends on:
Blocks:
 
 
Reported: 2012-04-19 17:47 UTC by Owen Taylor
Modified: 2012-07-02 10:25 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Fix the parsing of the dbus return, so valid information is passed to the user (1.58 KB, patch)
2012-07-02 06:58 UTC, Sjoerd Simons
committed Details | Review

Description Owen Taylor 2012-04-19 17:47:54 UTC
See full bug report at https://bugzilla.redhat.com/show_bug.cgi?id=810615

Basically, it looks like gnome-bluetooth/applet/bluetooth-applet.c:confirm_request() is emitting the
signal with a null name , which is causing the Bluetooth code in gnome-shell to produce a JS error- we could default name to <unknown> or something in gnome-shell, but probably it's better to handle things in gnome-bluetooth?

$ rpm -q bluez gnome-shell gnome-bluetooth
bluez-4.99-1.fc17.x86_64
gnome-shell-3.4.0-1.fc17.x86_64
gnome-bluetooth-3.4.0-1.fc17.x86_64
Comment 1 Giovanni Campagna 2012-04-19 18:37:47 UTC
The right place (and Bastien will confirm, I think) to work around this is gnome-bluetooth, as it already has some hacks for specific devices.
But I also see a critical trying to decode a GVariant, maybe it is a dbus failure down the stack?
Comment 2 Tom Horsley 2012-06-14 18:57:16 UTC
Search for gnome-bluetooth bugs on redhat bugzilla in fedora 17 and you will find lots of folks reporting they can no longer pair anything (with no comments from any maintainers as if the whole issue is being ignored in the hopes that it will go away :-).
Comment 3 Bastien Nocera 2012-06-14 19:43:00 UTC
(In reply to comment #2)
> Search for gnome-bluetooth bugs on redhat bugzilla in fedora 17 and you will
> find lots of folks reporting they can no longer pair anything

Which has nothing to do with this bug report.

> (with no comments
> from any maintainers as if the whole issue is being ignored in the hopes that
> it will go away :-).

Yeah, they might be too busy filing package updates.
Comment 4 Seán de Búrca 2012-06-27 22:27:36 UTC
I am also having this issue. What information can I provide to assist in debugging?
Comment 5 Bastien Nocera 2012-06-27 22:42:00 UTC
(In reply to comment #4)
> I am also having this issue. What information can I provide to assist in
> debugging?

I doubt this is the problem you're seeing. Make sure you're using gnome-bluetooth 3.4.1 and file a separate bug.
Comment 6 Seán de Búrca 2012-06-28 00:02:36 UTC
Symptoms appear to be identical, down to the contents of .xsession-errors, using gnome-bluetooth 3.4.1. Should I still file a separate bug?
Comment 7 Sjoerd Simons 2012-07-02 06:58:49 UTC
Created attachment 217802 [details] [review]
Fix the parsing of the dbus return, so valid information is passed to the user
Comment 8 Sjoerd Simons 2012-07-02 07:01:32 UTC
The pairing issues should be fixed with the above patch, given gnome-bluetooth falls back the Address in case there is no name it shouldn't really ever return a NULL. In case it does, either bluez broke or something else went horribly wrong then most likely the pairing attempt should be  aborted either by gnome-bluetooth or gnome-shell.
Comment 9 Bastien Nocera 2012-07-02 10:25:29 UTC
FWIW, I don't think this actually fixes the pairing itself, but it fixes the error gnome-shell threw.

The pairing problem itself was also fixed by Sjoerd in bug 679190, and was related to Simple Pairing (the "can you confirm the code" difference in the Fedora bug at https://bugzilla.redhat.com/show_bug.cgi?id=810615#c6 should have been the hint).