Bug#384379: [Pkg-bluetooth-maintainers] Bug#384379: WORK-AROUND for "iscan not set"

Hendrik Sattler debian at hendrik-sattler.de
Mon Jan 1 03:09:05 CET 2007


Happy New Year 2007.

Am Sonntag 31 Dezember 2006 16:22 schrieb Marcel Holtmann:
> > * plugging the dongle in and then chaning to "connectable" may be too
> > late Practically the same thing as the default from above.
>
> This is why we go back to non-discoverable after 180 seconds by default.
>
> Supporting these kind of strange setting would also mean that you know
> the address of the adapter you are gonna plug in up-front. In general
> you don't. Except you really know what you are doing and then no
> interface will fully suit you at all.

Well, it is a special case, I agree. But since you already plugged it in once, 
you can already know the address (ls /var/lib/bluetooth).

> > > > So is there an easy command line tool for all those dbus options
> > > > (except using raw dbus command)?: no == very bad usibility (and an
> > > > awful lot to type for one option)
> > > >
> > > > So how can you solve this problem with your input:
> > > > * ship the dbus API documenation in the binary packages
> > >
> > > Definitely.
> > >
> > > > * give the user and root a shell tool to make use of the things in
> > > > the bluez dbus API without getting bloody hands by using dbus-send
> > >
> > > Since we wanna avoid a Python dependency,
> >
> > Does that mean that there is such a tool?
>
> The apitest script could easily do this job or the dbusdef.py pre-load
> code are really helpful for testing. In general it is really simple to
> handle our D-Bus API from within Python. Most things are only a few
> lines of Python, but for a base package like bluez-utils you don't wanna
> have that dependency.

Pythong is priority standard. Ok not essential but looking at what already 
depends on python, it is most likely already installed.
I wouldn't mind it but I am not the bluez-utils maintainer ;)

HS




More information about the Pkg-bluetooth-maintainers mailing list