On Sun, Nov 12, 2006 at 11:19:30PM +0000, Nic James Ferrier wrote: > Filippo Giunchedi <[EMAIL PROTECTED]> writes: > > > On Sun, Nov 12, 2006 at 09:46:43PM +0000, Nic James Ferrier wrote: > >> Filippo Giunchedi <[EMAIL PROTECTED]> writes: > >> > >> > bluez-utils 3.7-1 has just migrated to testing today, so it should hit > >> > your > >> > nearest mirror tomorrow, please upgrade to 3.7-1 and don't forget to read > >> > /usr/share/doc/bluez-utils/README.Debian for instructions, the > >> > /etc/bluetooth/passkeys thing is gone. > >> > >> I don't agree that this problem has been fixed at all. > >> > >> You have simply removed the ability of non-GNOME clients (maybe > >> there's a KDE dbus client as well) to enter a passkey. > >> > >> I don't use GNOME. I don't use KDE. > > > > did you tested bluez-passkey-gnome (or bluez-gnome when it hits the archive) > > with other DEs and/or WMs? please provide examples of > > non-functionality > > I did. It's not really about other window managers... GNOME, as you > know, isn't a window manager. I imagine if I was using GNOME with any > Window Manager I could still use the GNOME bt-applet. But I don't use > GNOME so the applet can't possibly run. > > I can run it... but it has nowhere to live.
I haven't tested it, but even if you don't see the applet running it will popup the pin dialog nevertheless. This needs to be tested though. > > > please provide specific examples, I see dbus 0.94-1 in testing and -2 in > > unstable, is it going a transition? how does it breaks packages? > > Ok. > > Installation of python-dbus would cause these to be removed: > > openoffice.org* openoffice.org-help-en-us* openoffice.org-writer* > python-uno* python2.3-libxml2* > > python2.3-dbus depends on dbus-1 right now and that causes these to be > removed: > > bluetooth* bluez-passkey-gnome* bluez-utils* dbus* hal* powersaved* > > > Not good. I assumed you are running testing, is that right? Note that python2.3-dbus is not present in testing because of the python transition. > > > > I agree that the pincodes format is not documented in README.Debian, and > > that of > > course needs to be fixed. > > FWIW the format is generic for all the bluez storage and it is "key value" > > so in > > pincodes it should be "<remoteaddress> <pincode>" (beware of leading and > > trailing spaces if you are hand-editing the file, though. > > I did work it out. I was very cross about it though. > > > If I have time when the dbus situation is fixed I will write a python > tool to respond to dbus querys with a fixed pin. That's really all > that's needed. great, that'll be much appreciated. filippo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
