Bug#382269: [Pkg-bluetooth-maintainers] Bug#382269: Any progress?

[Nic James Ferrier]

Filippo Giunchedi <filippo at esaurito.net> writes:

> On Sun, Nov 12, 2006 at 09:46:43PM +0000, Nic James Ferrier wrote:
>> Filippo Giunchedi <filippo at esaurito.net> 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.

Of course... you could say: well run the panel. But running the
gnome-panel *is* running gnome and I don't want to run gnome.


> 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 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.


-- 
Nic Ferrier
http://www.tapsellferrier.co.uk   for all your tapsell ferrier needs