Today I've discovered that I can't browse or send files to my smartphone even if I've been able to do that, if I remember correctly. The error given by nautilus when I choose "browse files" from gnome-bluetooth tray icon (version ~2.28.6) is the following: "Method "CreateBluetoothSession" with signature "sss" on interface org.openobex.Manager" doesn't exist" So I've tried to list the files on my device: gnomevfs-ls "obex://[18:86:AC:95:F3:6C]/" Error opening: invalid URI I'm sorry if I'm pointing out your attention on a wrong package but I'm not really experienced with bluetooth things.
I'm currently using gnome-base/gnome-vfs-2.24.1
Created attachment 217803 [details] emerge --info
Thanks for report. Reassigning on maintainers.
I have the same problem with g-bt-2.28.6
g-bt-2.28.3 together with obex-data-server does work
As seen searching a bit, maybe this is caused by obexd :-/, maybe somebody could test on a local overlay with newer obexd (bug 297930) (I don't have much time now for it, sorry :-( )
(In reply to comment #6) > As seen searching a bit, maybe this is caused by obexd :-/, maybe somebody > could test on a local overlay with newer obexd (bug 297930) (I don't have much > time now for it, sorry :-( ) > doesn't work here. "Error: Method "CreateBluetoothSession" with signature "sss" on interface "org.openobex.Manager" doesn't exist" elbryan 3158 0.0 0.1 95056 3868 ? S 13:40 0:00 /usr/libexec/obexd --nodaemon --opp --ftp app-mobilephone/obexd Installed versions: 0.21[1](13:21:49 12/02/2010)(eds -debug)
What gvfs version do you have installed?
(In reply to comment #8) > What gvfs version do you have installed? > gnome-base/gvfs-1.4.3
Please note that anytime you install/remove a dbus service, you need to reload/restart dbus for the change to be effective.
(In reply to comment #10) > Please note that anytime you install/remove a dbus service, you need to > reload/restart dbus for the change to be effective. > I knew that and, in fact, I've entirely rebooted the system to exclude all the doubts.
I have been searching but I have failed to find who is the culprit (gnome-bluetooth, obexd, openobex...), I have also found some similar bug reports on debian and ubuntu but still unresolved :-(. Also, ubuntu, fedora, debian and mandriva packages seems to package these tools similar than us :-/ I have reported it to gnome-bluetooth maintainers, I hope they will know much better than me where could be the problem https://bugzilla.gnome.org/show_bug.cgi?id=609858
(In reply to comment #12) > I have been searching but I have failed to find who is the culprit > (gnome-bluetooth, obexd, openobex...), I have also found some similar bug > reports on debian and ubuntu but still unresolved :-(. Also, ubuntu, fedora, > debian and mandriva packages seems to package these tools similar than us :-/ > > I have reported it to gnome-bluetooth maintainers, I hope they will know much > better than me where could be the problem > https://bugzilla.gnome.org/show_bug.cgi?id=609858 > Thank you Pacho
As talked with upstream, the problem is downstream, since obexd and obex-data-server are both needed. I will then: 1. Check if both can be really installed on Gentoo (they should and seems that, at least, can coexist without colliding, but I need to check with my bluetooth if it's really working). If they work, I will drop their mutual blockers. 2. gnome-base/gvfs[bluetooth] needs to RDEPEND on app-mobilephone/obex-data-server as talked with upstream, seen in fedora's spec files and read in sources dir: (INSTALL file) The ObexFTP backend requires the obex-data-server D-Bus service in addition to the dependencies listed in the configure. See: http://wiki.muiline.com/obex-data-server
(In reply to comment #14) > As talked with upstream, the problem is downstream, since obexd and > obex-data-server are both needed. I will then: > 1. Check if both can be really installed on Gentoo (they should and seems that, > at least, can coexist without colliding, but I need to check with my bluetooth > if it's really working). If they work, I will drop their mutual blockers. > > 2. gnome-base/gvfs[bluetooth] needs to RDEPEND on > app-mobilephone/obex-data-server as talked with upstream, seen in fedora's spec > files and read in sources dir: (INSTALL file) > The ObexFTP backend requires the obex-data-server D-Bus service in > addition to the dependencies listed in the configure. See: > http://wiki.muiline.com/obex-data-server > So we (users) have only to wait? I can confirm that obex-data-server makes everything running fine but this requires obexd to be unmerged (as you stated in your previous post).
i believe bug 285043 needs to be mentioned here and vice versa?
I had thought, and it's been a while since I checked this, that both obex-data-server and obexd provide a bus that operates under the interface name "org.openobex.Manager", but that the interfaces are in fact different (hence the error message you've discovered in the first place). I'm not sure whether both can hold the same interface name with different interfaces at the same time, but I can envisage it causing major problems. It's entirely unclear how openobex, gnome and bluez all operate together. It appears bluez has a gnome package (bluez-gnome) and that gnome has a bluez package (gnome-bluez). Bluez appears to have created their own obex service after seeing how good openobex's data server was, but it doesn't appear as though they were designed to be drop-in replacements for each other, but more competing versions of the same thing. So the question then becomes how to get all the possible packages working neatly together? Should users go bluez-only, which should be API stable (since it's all made by the same group) but can be slow to update the peripheral programs, or should they be going with all the other bits and pieces (gnome, openobex, obex-data-server, etc) at the risk of not having everything work together smoothly? Is anyone able to shed any light on how everything fits together and what interacts properly with what? At the moment it seems a bit of a mess, and that's going to play havoc with the dependencies...
At the moment, the idea is to try to get both installed on the system since it seems that it's what we should do as talked with Bastien Nocera in https://bugzilla.gnome.org/show_bug.cgi?id=609858 but, first, I need to really try if they work ok together (well, fedora is providing both and seems to work ok, but I prefer to try it myself) and, once I test it, I will probably commit the changes for being able to have both (obexd and obex-data-server) installed at the same time. In summary: - obexd is needed by gnome-bluetooth for "send to" - gvfs-obexftp backend (-> gvfs with USE "bluetooth" enabled) RDEPENDs on obex-data-server (current RDEPEND is incomplete, please read http://git.gnome.org/browse/gvfs/tree/INSTALL for confirming it. - gvfs-obexftp is needed by gnome-bluetooth for "brows files" function
Ok, soooo, according to a Debian developer (see the end of [1]), "no GNOME package actually make use of obexd-server at the moment." That's mentioned in several of their bugs, but seems to refer to the server component of obexd and not the client component. Here's another more detailed debian report [2] that might shed some light on the situation. The current solution seems to be to split obexd into client and server, since there *is* a conflict (both servers provide the same Dbus interface), but it's only between the servers, and not the obexd-client. It appears to be the obexd-client bit that's needed by gnome (see bug 285043 comment 14 and 15). I can't do as much testing as I used to, since I no longer have immediate access to a bluetooth device with an Obex stack that isn't bluez. As far as I can tell, someone somewhere screwed up and re-used the same DBus namespace, but used a different interface. I'm pretty sure all of this could have been avoided with proper consideration for naming... 5:\ [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=564162 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=565318
(In reply to comment #19) > Ok, soooo, according to a Debian developer (see the end of [1]), "no GNOME > package actually make use of obexd-server at the moment." That's mentioned in > several of their bugs, but seems to refer to the server component of obexd and > not the client component. Yes, for example, fedora's obexd.spec file shows that server component is not being built: http://cvs.fedoraproject.org/viewvc/devel/obexd/obexd.spec?revision=1.21&view=markup > Here's another more detailed debian report [2] that > might shed some light on the situation. > > The current solution seems to be to split obexd into client and server, since > there *is* a conflict (both servers provide the same Dbus interface), but it's > only between the servers, and not the obexd-client. It appears to be the > obexd-client bit that's needed by gnome (see bug 285043 comment 14 and 15). > > I can't do as much testing as I used to, since I no longer have immediate > access to a bluetooth device with an Obex stack that isn't bluez. > > As far as I can tell, someone somewhere screwed up and re-used the same DBus > namespace, but used a different interface. I'm pretty sure all of this could > have been avoided with proper consideration for naming... 5:\ > > [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=564162 > [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=565318 > Thanks a lot for pointing to these for the server incompatibility
I have just committed new app-mobilephone/obexd and app-mobilephone/obex-data-server , please try them
(In reply to comment #21) > I have just committed new app-mobilephone/obexd and > app-mobilephone/obex-data-server , please try them > It doesn't work (nor with -server or +server). obex-data-server isn't pulled by obexd nor gnome-bluetooth-2.28.6 so should I emerge manually obex-data-server?
(In reply to comment #22) > It doesn't work (nor with -server or +server). What doesn't work? > > obex-data-server isn't pulled by obexd nor gnome-bluetooth-2.28.6 so should I > emerge manually obex-data-server? > It should be pulled in by gvfs, but I still haven't changed gvfs RDEPEND, then, for now, simply run "emerge -1 obexd obex-data-server"
Also remember comment #10 (for example, I rebooted for trying it since I also updated by kernel ;-))
Ok. With app-mobilephone/obexd-0.21-r1[-server] _but without_ app-mobilephone/obex-data-server the error is the following: Errore: The name org.openobex was not provided by any .service files Emerging app-mobilephone/obex-data-server-0.4.4 everything starts running smoothly.
(In reply to comment #25) > Ok. > With app-mobilephone/obexd-0.21-r1[-server] _but without_ > app-mobilephone/obex-data-server the error is the following: > > Errore: The name org.openobex was not provided by any .service files It's expected I will consult the rest of gnome team about gvfs RDEPEND on obex-data-server as upstream requires
I have already fixed gvfs RDEPEND for gnome-base/gvfs-1.4* 1.2 is still untouched since we have to wait for bug 305913 and 305875
(In reply to comment #27) > I have already fixed gvfs RDEPEND for gnome-base/gvfs-1.4* > > 1.2 is still untouched since we have to wait for bug 305913 and 305875 > Since Gnome 2.28 is already going stable, we won't fix this for gvfs-1.2*. All we (gnome team) can do is done. Now, remaining bugs (305875, 305913) depends on arch teams
