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

[Filippo Giunchedi]

On Sun, Nov 12, 2006 at 11:19:30PM +0000, Nic James Ferrier wrote:
> 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.

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