Hello Marcel,

On Mon, Sep 04, 2006 at 02:11:52PM +0200, Marcel Holtmann wrote:
> > > > bluez-libs compiled out of the box by just unpacking and moving the
> > > > debian directory over, but bluez-utils needs some work:
> > > > 
> > > > * remove bluez-bcm203x package (bcm203x firmware loader removed upstream)
> > > 
> > > Not needed at all. You don't wanna support a 2.4 kernel and even if you
> > > really want to, you won't find any of these devices anymore. For all 2.6
> > > kernels the bcm203x kernel module takes care of loading the firmware.
> > 
> > I'm going to drop it after etch release when we'll discontinue support for 2.4
> > kernels.
> 
> You can drop it now actually. A Liunx 2.4 kernel user and owner of this
> device is a really really unlikely combination. I mean it. It would take
> me at least a couple of hours to find my dongle.

good luck with finding your dongle :)
anyway, as rare as it is etch is going to support 2.4 kernels.

> 
> > > This package has to die and from an USB and udev perspective it was a
> > > really nasty hack.
> > > 
> > > > * remove 000_rfcomm_conf_example.patch: the example is already commented
> > > > * remove 004_rfcomm_usage.patch: applied upstream
> > > 
> > > Sometimes it is a good idea to feed patches back to upstream so I don't
> > > have to extract them from the packages.
> > 
> > yep, I'm used to do it, I must have overlooked these patches.
> 
> Do you have any other patches that are not upstream?

I'm looking at them one by one, bluez debian packages are maintained with svn.
You can browse the patches for bluez-utils at
http://svn.debian.org/wsvn/pkg-bluetooth/bluez-utils/trunk/debian/patches/?rev=0&sc=0

you might be interested in:

http://svn.debian.org/wsvn/pkg-bluetooth/bluez-utils/trunk/debian/patches/007_hcid_typo.patch?op=file&rev=0&sc=0
which fixes a small typo in hcid

http://svn.debian.org/wsvn/pkg-bluetooth/bluez-utils/trunk/debian/patches/008_pand_man.patch?op=file&rev=0&sc=0
addition for pand manpage referring /etc/bluetooth/pan/dev-up execution

http://svn.debian.org/wsvn/pkg-bluetooth/bluez-utils/trunk/debian/patches/006_xsims.patch?op=file&rev=0&sc=0
more compatible usage of test in bluetooth.init and hsplay

[snip]

> And please drop your passkey agent think completely. This will be
> distribution specific and can't be a solution. It is better to put the
> passkey-agent.c example in the docs directory as an example and mention
> it in a README.Debian.
> 
> That said. I am missing a package for bluez-gnome which contains the
> graphical passkey agent. New version is coming up also this week. It
> will fix a small glitch with the status icon.

indeed, how about this plan:

- I will add to bluez-utils a default non-interactive passkey agent (more or less
  like now but less hackish) which uses /etc/bluetooth/passkeys/<bt_addr> like
  now
- bluez-gnome will provide the graphical passkey agent which takes over the
  non-interactive one

Marcel: can agents be "stackable", that is, if two agents are registered and
first one doesn't supply an answer, the second will?

comments?

filippo
--
Filippo Giunchedi - http://esaurito.net
PGP key: 0x6B79D401
random quote follows:

Age is not a particularly interesting subject. Anyone can get old. All
you have to do is live long enough.
-- Groucho Marx