Description of problem: bluez-utils is useful, even on text-mode and headless systems. The Fedora package for bluez-utils explicitly requires bluez-gnome though. This means that a 374K rpm of CLI utilities and daemons depends on 13M of gnome and xorg rpms. Pretty sure the fix is to remove "Requires: bluez-gnome" from bluez-utils. Version-Release number of selected component (if applicable): 3.7-2 How reproducible: Inherent to current bluez-utils release. Steps to Reproduce: 1. rpm -qp --requires bluez-utils-3.7-2.i386.rpm | grep bluez Actual results: >>rpm -qp --requires bluez-utils-3.7-2.i386.rpm | grep bluez bluez-gnome bluez-libs >= 3.7 config(bluez-utils) = 3.7-2 Expected results: >>rpm -qp --requires bluez-utils-3.7-2.i386.rpm | grep bluez bluez-libs >= 3.7 config(bluez-utils) = 3.7-2 Additional info: This isn't a new problem. Before the recent update, bluez-utils used to depend on bluez-pin. With the change though, it's very clear that bluez-gnome is a gnome UI app, and as noted previously, bluez-utils is functional without it.
hcid now uses dbus unconditionally for fetching a PIN. I don't see any alternative to requiring bluez-gnome. Marcel?
Actually you can either use bluez-gnome of kdebluetooth or whatever passkey agent you wanna use. I think that a suggests is more appropriate than a requires. The BlueZ passkey agent interface is designed to serve all kinds of purposes and is fully generic. The bluetooth-applet from bluez-gnome is only one way to get achieve a proper PIN input.
We can't do 'suggests'. We could have a virtual 'bluez-pinhelper' which is provided by any passkey agent, so that you can use kdebluetooth or some other possibility.
*** Bug 248440 has been marked as a duplicate of this bug. ***
You better call it bluez-passkey or bluez-passkey-agent. The term PIN helper refers to the old system and is no longer in use. However besides the passkey agent we also have the authorization agent. So we might wanna use a more generic term. I would propose bluetooth-ui or something like that. Do we have a virtual package bluetooth so you can simply do a yum install bluetooth and the basic components are installed.
*** Bug 212825 has been marked as a duplicate of this bug. ***
Should we be shipping the passkey agent and authorisation agent which are part of the bluez-utils package? If so, in what form? No, we don't have a virtual 'bluetooth' package. We install the bluetooth packages by default.
A system can be used without any passkey agents. For some use cases you don't need a PIN code at all. The authorization agent is not asked if you for example use SetTrusted() to fully trust a remote device. The whole idea is to have a fully modular system and make the UI easy replaceable. So no passkey agent and no authorization agent should be part or required by bluez-utils. However when you install a GNOME desktop you should make sure that bluez-gnome is also installed.
(In reply to comment #1) > hcid now uses dbus unconditionally for fetching a PIN. I don't see any > alternative to requiring bluez-gnome. Marcel? Some hardware don't need any passkeys. For example Apple Wireles Mighty Mouse. All I need to use it under Linux may be done in three steps: * install bluez-libs and bluez-utils * get its ID by hciotool scan * add to /etc/rc.d/rc.local new string: hidd -c ID That's all. No need to Gnome cra... stuff.
Your point is correct, but your example is wrong. The Apple Wireless Mouse indeed requests a PIN code. It is 0000.
bluez-gnome is installed in the default installation. Maybe we shouldn't force bluez-utils to require it, and let the package/system installers deal with that problem by themselves. The problem isn't so uncommon for other applications...
kdebluetooth now supports the DBUS method for retreiving/setting pins, so maybe there's some virtual Provides that both bluez-gnome and kdebluetooth can provide?
Gilboa, are you ok with a virtual provides? What should we call it?
Yes. How about provides: dbus-pin-handler? BTW, do you plan on getting this change in before F8-release? - Gilboa
(In reply to comment #14) > Yes. > How about provides: dbus-pin-handler? Yep. I used dbus-bluez-pin-helper (helper is what BlueZ uses in in config, and I'd rather add "bluez" in there to avoid possible conflicts) in bluez-utils-3.20-2, and bluez-gnome-0.14-7 Please close the bug once you've done the kdebluetooth build.
A new kdebluetooth build is out. (With provides: dbus-bluez-pin-helper). Closing BZ.
kdebluetooth-1.0-0.34.beta8.fc7 has been pushed to the Fedora 7 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update kdebluetooth'
kdebluetooth-1.0-0.34.beta8.fc7 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report.
I would like to maybe reopen this. I work on embedded systems and really, really don't want to include Gnome (gtk, the whole X, etc). The problem is not so much bluez-gnome is a dependency, but it in turn is dependent on the whole graphical desktop. The project is for a wifi-to-bluetooth (and maybe i2c sensor) gateway so I could use any smartphone via a web server. I will need pins, but those can be preset. This is like requiring the gnome-desktop if you want to use USB. The PIN problem is fixed by any of several simple python scripts or programs using dbus. The problem is it becomes impossible to use RPM or YUM to install things to my system if it is going to insist on including hundreds of megabytes of things I will never use, and don't want.
I should add that I would be willing to work on and contribute an alternate means of getting PIN numbers. Ultimately I will need something for my web interface project, and the test-agent works and I have already modified it. If I create a bluez-scriptable-pin package or something similar, would it help?