[Bluez-devel] Dealing with the bluez-utils dependencies

[Bluez-devel] Dealing with the bluez-utils dependencies

[Marcel Holtmann]

Hi Folks,

the dependency list of bluez-utils is going to be crazy and I think we
need to work on some parts. I can't be possible that if you install
bluez-utils that GTK+ and Python will be installed in some cases.

The base dependency is the C library and bluez-libs or libbluetooth and
this will not change of course ;)

So lets talk about the other packages we need and use. The first one is
the USB library that we need. It is used by hid2hci, bcm203x and dfutool
programs. While bcm203x is only needed for the 2.4 kernel series and
should be always kept as a separate package, I don't consider this a
problem. Most modern distributions won't need this tool. The dfutool is
only needed by developers and people that play with firmware upgrades.
However it might be handy to create a bluez-devel packages that depends
on the Bluetooth library header files and gives you special tools for
the developers. Such a package may also contain the *test applications.
However I think that people who wants to play with firmware upgrades
should maybe better compile dfutool by themself. So at least it is not
that easy to screw a Bluetooth device and then try to blame others. My
only problematic tool left with USB dependency is hid2hci and this is
really needed for all of you using HID Proxy dongles. So do you think a
general dependency on the USB library is fine for a bluez-utils binary
package?

Next big thing is the D-Bus library. We use D-Bus in hcid and it seems
that people are working on D-Bus support for pand. Personal I am not a
big believer in D-Bus anymore, but it gets used and so we can't avoid
it. So should we leave that a compile time option and by default we
enable it. The bluez-utils binary package then simply depends on the
D-Bus library?

With configure we also check for OpenOBEX and ALSA. The OpenOBEX part is
not ready at the moment and still part of its own in the CVS. For ALSA
we now have the first draft of an A2DP plugin. However I think most
packages maintainers will create a bluez-alsa package for it and this
looks like a sane thing to me.

And now the really ugly part. The PIN helper support. This is the real
pain and we should find a nice solution for it. The original Python
script is not an option, because it depends on Python and even the GTK
PIN helper will add the GTK+ libraries. Also the KDE Bluetooth project
has its own PIN helper. I personal like to go with the SuSE idea to
provide a general PIN helper script that checks the installed tools and
then executes the right PIN helper or provides a default PIN (or no PIN)
if nothing has been setup. We can also add more config options, where we
provide a list of PIN helpers that will tried one after the other. Maybe
also a default PIN option would be a good idea. Comments please.

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Dealing with the bluez-utils dependencies

[Claudio Takahasi]

Hi Marcel,

Regarding D-Bus support for pand and hcid.=20
DBUS is under development and there is backward compatibility problem.
Some APIs changed, I suggest check the dbus version at build time=20
and fix the code to support this. The latest version(0.33) is not compatibl=
e
with 0.23.


Regards,
Claudio




On 5/10/05, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Folks,
>=20
> the dependency list of bluez-utils is going to be crazy and I think we
> need to work on some parts. I can't be possible that if you install
> bluez-utils that GTK+ and Python will be installed in some cases.
>=20
> The base dependency is the C library and bluez-libs or libbluetooth and
> this will not change of course ;)
>=20
> So lets talk about the other packages we need and use. The first one is
> the USB library that we need. It is used by hid2hci, bcm203x and dfutool
> programs. While bcm203x is only needed for the 2.4 kernel series and
> should be always kept as a separate package, I don't consider this a
> problem. Most modern distributions won't need this tool. The dfutool is
> only needed by developers and people that play with firmware upgrades.
> However it might be handy to create a bluez-devel packages that depends
> on the Bluetooth library header files and gives you special tools for
> the developers. Such a package may also contain the *test applications.
> However I think that people who wants to play with firmware upgrades
> should maybe better compile dfutool by themself. So at least it is not
> that easy to screw a Bluetooth device and then try to blame others. My
> only problematic tool left with USB dependency is hid2hci and this is
> really needed for all of you using HID Proxy dongles. So do you think a
> general dependency on the USB library is fine for a bluez-utils binary
> package?
>=20
> Next big thing is the D-Bus library. We use D-Bus in hcid and it seems
> that people are working on D-Bus support for pand. Personal I am not a
> big believer in D-Bus anymore, but it gets used and so we can't avoid
> it. So should we leave that a compile time option and by default we
> enable it. The bluez-utils binary package then simply depends on the
> D-Bus library?
>=20
> With configure we also check for OpenOBEX and ALSA. The OpenOBEX part is
> not ready at the moment and still part of its own in the CVS. For ALSA
> we now have the first draft of an A2DP plugin. However I think most
> packages maintainers will create a bluez-alsa package for it and this
> looks like a sane thing to me.
>=20
> And now the really ugly part. The PIN helper support. This is the real
> pain and we should find a nice solution for it. The original Python
> script is not an option, because it depends on Python and even the GTK
> PIN helper will add the GTK+ libraries. Also the KDE Bluetooth project
> has its own PIN helper. I personal like to go with the SuSE idea to
> provide a general PIN helper script that checks the installed tools and
> then executes the right PIN helper or provides a default PIN (or no PIN)
> if nothing has been setup. We can also add more config options, where we
> provide a list of PIN helpers that will tried one after the other. Maybe
> also a default PIN option would be a good idea. Comments please.
>=20
> Regards
>=20
> Marcel
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_id=3D7393&alloc_id=3D16281&op=3Dclick
> _______________________________________________
> Bluez-devel mailing list
> Bluez-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>=20


--=20
_______________________________________
Claudio Takahasi
INdT - Nokia Technology Institute
Phone: +55 81 21223034
Recife - Pernambuco - Brazil


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Dealing with the bluez-utils dependencies

[Marcel Holtmann]

Hi Claudio,

> Regarding D-Bus support for pand and hcid. 
> DBUS is under development and there is backward compatibility problem.
> Some APIs changed, I suggest check the dbus version at build time 
> and fix the code to support this. The latest version(0.33) is not compatible
> with 0.23.

as I said before, send patches for it.

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Dealing with the bluez-utils dependencies

[Claudio Takahasi]

Hi Marcel,

I will send as soon as possible. This week is being very tumultuated
for me.=20

Who is the focal point/contact of hcid? I want contact him for verify
if this patch will NOT broke something.

Regards,
Claudio.

On 5/12/05, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Claudio,
>=20
> > Regarding D-Bus support for pand and hcid.
> > DBUS is under development and there is backward compatibility problem.
> > Some APIs changed, I suggest check the dbus version at build time
> > and fix the code to support this. The latest version(0.33) is not compa=
tible
> > with 0.23.
>=20
> as I said before, send patches for it.
>=20
> Regards
>=20
> Marcel
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_id=3D7393&alloc_id=3D16281&op=3Dclick
> _______________________________________________
> Bluez-devel mailing list
> Bluez-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Dealing with the bluez-utils dependencies

[Marcel Holtmann]

Hi Claudio,

> I will send as soon as possible. This week is being very tumultuated
> for me. 
> 
> Who is the focal point/contact of hcid? I want contact him for verify
> if this patch will NOT broke something.

post it to the mailing list for review. I will do the final decision of
including it or not.

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Dealing with the bluez-utils dependencies

[Claudio Takahasi]

Hi Marcel,

After lost a lot of time trying change the code to support
DBUS version 0.33 I was informed that the code for get byte=20
arrays is broken.

I decided develop the PAND DBUS support based on dbus 0.23.
At least, this version works and there is debian distribution!
I can make a workaround using version 0.23 and when a new
DBUS stable version became available I can fix my part.

When I was navigating in the BlueZ source code, I notice that
bluez-pin is using DBUS service too. Therefore, there is two
applications using DBUS 0.23: bluez-pin and hcid=20

This week I will post my initial draft of DBUS PAND service.

Regards,
Claudio.

On 5/12/05, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Claudio,
>=20
> > I will send as soon as possible. This week is being very tumultuated
> > for me.
> >
> > Who is the focal point/contact of hcid? I want contact him for verify
> > if this patch will NOT broke something.
>=20
> post it to the mailing list for review. I will do the final decision of
> including it or not.
>=20
> Regards
>=20
> Marcel
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_id=3D7393&alloc_id=3D16281&op=3Dclick
> _______________________________________________
> Bluez-devel mailing list
> Bluez-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Dealing with the bluez-utils dependencies

[Marcel Holtmann]

Hi Claudio,

> After lost a lot of time trying change the code to support
> DBUS version 0.33 I was informed that the code for get byte 
> arrays is broken.

check the bluez-utils CVS. I added a D-Bus patch from the Fedore Core
packages to workaround some API changes.

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Dealing with the bluez-utils dependencies

[Brad Midgley]

Marcel

> So lets talk about the other packages we need and use. The first one is
> the USB library that we need. It is used by hid2hci
...
> really needed for all of you using HID Proxy dongles. So do you think a
> general dependency on the USB library is fine for a bluez-utils binary
> package?

yes, this seems unavoidable unless you wanted to move hid2hci into a new 
package or make it an optional build. it seems best where it is now.

on a related note, what is happening with utils2 and libs2 in cvs?

> enable it. The bluez-utils binary package then simply depends on the
> D-Bus library?

some of the hcid pin stuff would have to be rewritten around no d-bus, 
right? but that seems like a low priority.

> With configure we also check for OpenOBEX and ALSA. The OpenOBEX part is
> not ready at the moment and still part of its own in the CVS. For ALSA
> we now have the first draft of an A2DP plugin. However I think most
> packages maintainers will create a bluez-alsa package for it and this
> looks like a sane thing to me.

right, so it's not a core dependency.

> PIN helper will add the GTK+ libraries. Also the KDE Bluetooth project
> has its own PIN helper. I personal like to go with the SuSE idea to
> provide a general PIN helper script that checks the installed tools

the helper script sounds reasonable. would the gnome folks be willing to 
maintain the gtk helper like kde does their own? It seems like kde is 
doing more to make bluez easy to use--gnome devels should take this as a 
challenge.

bluez could have a package that contains just the gtk pin tool just for 
gnome users with the idea that gnome should adopt it.

Brad


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Dealing with the bluez-utils dependencies

[Marcel Holtmann]

Hi Brad,

> > So lets talk about the other packages we need and use. The first one is
> > the USB library that we need. It is used by hid2hci
> ...
> > really needed for all of you using HID Proxy dongles. So do you think a
> > general dependency on the USB library is fine for a bluez-utils binary
> > package?
> 
> yes, this seems unavoidable unless you wanted to move hid2hci into a new 
> package or make it an optional build. it seems best where it is now.

I agree and creating an own package for it sounds like too much
overhead.

So keeping the USB library dependency for a binary package is ok. The
embedded people need to recompile with USB support.

> on a related note, what is happening with utils2 and libs2 in cvs?

They are meant to be the next generation, but then I started to backport
features and we still have the 2.x generation. The API breakage is too
big and I will only work on it again, when we get clarification about
LGPL for the Bluetooth library from Qualcomm.

> > enable it. The bluez-utils binary package then simply depends on the
> > D-Bus library?
> 
> some of the hcid pin stuff would have to be rewritten around no d-bus, 
> right? but that seems like a low priority.

All the PIN stuff is also working without D-Bus support.

> > With configure we also check for OpenOBEX and ALSA. The OpenOBEX part is
> > not ready at the moment and still part of its own in the CVS. For ALSA
> > we now have the first draft of an A2DP plugin. However I think most
> > packages maintainers will create a bluez-alsa package for it and this
> > looks like a sane thing to me.
> 
> right, so it's not a core dependency.

However the ALSA library 1.0.9 must be released first.

> > PIN helper will add the GTK+ libraries. Also the KDE Bluetooth project
> > has its own PIN helper. I personal like to go with the SuSE idea to
> > provide a general PIN helper script that checks the installed tools
> 
> the helper script sounds reasonable. would the gnome folks be willing to 
> maintain the gtk helper like kde does their own? It seems like kde is 
> doing more to make bluez easy to use--gnome devels should take this as a 
> challenge.
> 
> bluez could have a package that contains just the gtk pin tool just for 
> gnome users with the idea that gnome should adopt it.

It is already an own package called bluez-pin and not maintained by me.
The problem is that for example the Debian bluez-utils package depends
on bluez-pin and thus the dependency chain increases.

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Dealing with the bluez-utils dependencies

[Claudio Takahasi]

Hi Marcel,

Regarding D-Bus support for pand and hcid.
DBUS is under development and there is backward compatibility problem.
Some APIs changed, I suggest check the dbus version at build time
and fix the code to support this. The latest version(0.33) is not compatibl=
e
with 0.23.

Regards,
Claudio


On 5/10/05, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Brad,
>=20
> > > So lets talk about the other packages we need and use. The first one =
is
> > > the USB library that we need. It is used by hid2hci
> > ...
> > > really needed for all of you using HID Proxy dongles. So do you think=
 a
> > > general dependency on the USB library is fine for a bluez-utils binar=
y
> > > package?
> >
> > yes, this seems unavoidable unless you wanted to move hid2hci into a ne=
w
> > package or make it an optional build. it seems best where it is now.
>=20
> I agree and creating an own package for it sounds like too much
> overhead.
>=20
> So keeping the USB library dependency for a binary package is ok. The
> embedded people need to recompile with USB support.
>=20
> > on a related note, what is happening with utils2 and libs2 in cvs?
>=20
> They are meant to be the next generation, but then I started to backport
> features and we still have the 2.x generation. The API breakage is too
> big and I will only work on it again, when we get clarification about
> LGPL for the Bluetooth library from Qualcomm.
>=20
> > > enable it. The bluez-utils binary package then simply depends on the
> > > D-Bus library?
> >
> > some of the hcid pin stuff would have to be rewritten around no d-bus,
> > right? but that seems like a low priority.
>=20
> All the PIN stuff is also working without D-Bus support.
>=20
> > > With configure we also check for OpenOBEX and ALSA. The OpenOBEX part=
 is
> > > not ready at the moment and still part of its own in the CVS. For ALS=
A
> > > we now have the first draft of an A2DP plugin. However I think most
> > > packages maintainers will create a bluez-alsa package for it and this
> > > looks like a sane thing to me.
> >
> > right, so it's not a core dependency.
>=20
> However the ALSA library 1.0.9 must be released first.
>=20
> > > PIN helper will add the GTK+ libraries. Also the KDE Bluetooth projec=
t
> > > has its own PIN helper. I personal like to go with the SuSE idea to
> > > provide a general PIN helper script that checks the installed tools
> >
> > the helper script sounds reasonable. would the gnome folks be willing t=
o
> > maintain the gtk helper like kde does their own? It seems like kde is
> > doing more to make bluez easy to use--gnome devels should take this as =
a
> > challenge.
> >
> > bluez could have a package that contains just the gtk pin tool just for
> > gnome users with the idea that gnome should adopt it.
>=20
> It is already an own package called bluez-pin and not maintained by me.
> The problem is that for example the Debian bluez-utils package depends
> on bluez-pin and thus the dependency chain increases.
>=20
> Regards
>=20
> Marcel
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_id=3D7393&alloc_id=3D16281&op=3Dclick
> _______________________________________________
> Bluez-devel mailing list
> Bluez-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Dealing with the bluez-utils dependencies

[Marcel Holtmann]

Hi Claudio,

> Regarding D-Bus support for pand and hcid.
> DBUS is under development and there is backward compatibility problem.
> Some APIs changed, I suggest check the dbus version at build time
> and fix the code to support this. The latest version(0.33) is not compatible
> with 0.23.

I am not the D-Bus expert here. So send me patches. However I am fine
with only supporting the latest version, because it is still an optional
feature.

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Dealing with the bluez-utils dependencies

[Brad Midgley]

Marcel

> So keeping the USB library dependency for a binary package is ok. The
> embedded people need to recompile with USB support.

if embedded users complain, have them make hid2hci etc building optional.

> All the PIN stuff is also working without D-Bus support.

oh, well that's good.

> It is already an own package called bluez-pin and not maintained by me.
> The problem is that for example the Debian bluez-utils package depends
> on bluez-pin and thus the dependency chain increases.

it could be changed to a recommendation if things are set up to fall 
back to a fixed pin number. it might be a lot of trouble if it's not 
required on the user side. i was pleasantly surprised the first time it 
"just worked" and ran the gtk pin gui.

brad


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Dealing with the bluez-utils dependencies

[Marcel Holtmann]

Hi Brad,

> > It is already an own package called bluez-pin and not maintained by me.
> > The problem is that for example the Debian bluez-utils package depends
> > on bluez-pin and thus the dependency chain increases.
> 
> it could be changed to a recommendation if things are set up to fall 
> back to a fixed pin number. it might be a lot of trouble if it's not 
> required on the user side. i was pleasantly surprised the first time it 
> "just worked" and ran the gtk pin gui.

this is nice, but I still want something to satisfy terminal, X11, Gnome
and KDE users as well. In general it should not be necessary to touch
hcid.conf or modify the PIN helper. Only install the correct packages or
be happy with the default PIN.

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel