Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#20219 - obex-client installs in /usr/lib instead of /usr/libexec

Attached to Project: Arch Linux
Opened by Mihail (pevzi) - Monday, 19 July 2010, 11:34 GMT
Last edited by Andrea Scarpino (BaSh) - Tuesday, 20 July 2010, 08:41 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Andrea Scarpino (BaSh)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description:
The binary file obex-client from package obexd-client installs in /usr/lib instead of /usr/libexec, so that blueman and gnome-bluetooth don't work correctly.

Package version:
obexd-client: 0.29-2

Steps to reproduce:
When trying to send a file using gnome-bluetooth, it shows an error: «Failed to execute program /usr/libexec/obexd: Success». When trying to open files on a remote device using blueman, nautilus says, that it can't browse obex:// links.
This task depends upon

Closed by  Andrea Scarpino (BaSh)
Tuesday, 20 July 2010, 08:41 GMT
Reason for closing:  Fixed
Additional comments about closing:  obexd-* 0.29-3
Comment by Laurent Carlier (lordheavy) - Monday, 19 July 2010, 11:50 GMT
/usr/libexec isn't FHS compliant, so the problem must be in nautilus and/or gnome-bluetooth
Comment by Ionut Biru (wonder) - Monday, 19 July 2010, 12:00 GMT
blueman and nautilus works for me to browse my cellphone files. but i don't have obex-client installed

nautilus is using gvfs and his component gvfs-obexftp
Comment by Mihail (pevzi) - Monday, 19 July 2010, 12:20 GMT
Hm, that's my fault, blueman+nautilus really work without obexd-client. They didn't work before, so maybe this problem solved after the last upgrade (:

But there's still a problem with gnome-bluetooth — it still tries to run obex-client from /usr/libexec.
Comment by Ionut Biru (wonder) - Monday, 19 July 2010, 12:30 GMT
still can i cannot replicate it.

do you have gnome-user-share installed?
Comment by Mihail (pevzi) - Monday, 19 July 2010, 13:11 GMT
Thank you, that worked. Sorry for a false alarm (:
Comment by Ionut Biru (wonder) - Monday, 19 July 2010, 13:12 GMT
how did you made it work?
Comment by Mihail (pevzi) - Monday, 19 July 2010, 13:17 GMT
To be honest, I don't know :D I have installed gnome-user-share and saw gnome-bluetooth working. After removing it I saw that everything still works.
Comment by Ionut Biru (wonder) - Monday, 19 July 2010, 13:21 GMT
the thing is that Andrea when adding the split build to add the server, he removed libexecdir argument.

http://repos.archlinux.org/wsvn/packages/obexd/trunk/PKGBUILD?op=diff&rev=85417&peg=85417

and /usr/share/dbus-1/services/obex-client.service contains this entry:

Exec=/usr/libexec/obex-client

so clearly is a packaging bug
Comment by Mihail (pevzi) - Monday, 19 July 2010, 13:31 GMT
Ouch, now I understand where the problem is. Thank you for such a quick reply (:
Comment by Jan de Groot (JGC) - Monday, 19 July 2010, 14:06 GMT
I fixed this bug in SVN trunk. I would like to know how the maintainer intends to fix the duplicate installation of an obex data server? At this moment both obex-data-server and obexd-server provide the org.openobex dbus interface, but they're incompatible and are conflicting. It's possible to install both of these things in parallel, but only one of the servers can run at the same time. To make things worse, applications have no control over which of these two is spawned when requested through dbus.
Comment by Andrea Scarpino (BaSh) - Monday, 19 July 2010, 19:22 GMT
I'll fix this like Debian does. I'll rename the obex-data-server openobex dbus interface as obex-data-server.service but I didn't really look well on this. Anyway, I've the hardware to do some test (not the time right now). I'll look better on this tomorrow or Wednesday
Comment by Ionut Biru (wonder) - Monday, 19 July 2010, 19:59 GMT
i'm sorry but i don't think that renaming the interface is a good solution.

debian doesn't even do what you said.

http://patch-tracker.debian.org/patch/debianonly/view/obexd/0.28-1
http://patch-tracker.debian.org/patch/debianonly/view/obex-data-server/0.4.5-1

obexd-server conflicts with obex-data-server. that's the way they do it. the same solution is done on gentoo
Comment by Andrea Scarpino (BaSh) - Monday, 19 July 2010, 22:05 GMT
http://packages.debian.org/sid/i386/obex-data-server/filelist
Comment by Jan de Groot (JGC) - Monday, 19 July 2010, 22:08 GMT
obex-data-server package already has that filename for the service file, but the interfaces on dbus are named the same, so these packages are conflicting. There can be only one instance of these packages active at the same time, and besides specifically launching a binary, applications have no control over which one to start. Once one of these daemons is started, it's impossible to start the other one.
Comment by Ionut Biru (wonder) - Monday, 19 July 2010, 22:46 GMT
Andrea we are talking about the content inside /usr/share/dbus-1/services/obex-data-server.service and /usr/share/dbus-1/services/obexd.service

both have the same interface name
Comment by Andrea Scarpino (BaSh) - Monday, 19 July 2010, 23:48 GMT
Ooops...too much studying and work

Loading...