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
signature.asc
Description: Digital signature