Bug#385857: [Bluez-devel] Bug#385857: [Pkg-bluetooth-maintainers] Bug#385857: please upgrade to bluez-utils and bluez-libs 3.4
Hi Filippo, > > > > > 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. your choice, but it is no longer part of bluez-utils. > > > > 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 These two patches were already in the CVS. > 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 Added this one. This will get you down to two. > > 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/ like > now Doesn't make sense, because it is distro specific and you duplicate functionality that is already present. Don't do this. This stuff must die. I am serious about it. > - bluez-gnome will provide the graphical passkey agent which takes over the > non-interactive one Make sure you deprecate bluez-pin, because that one is no longer working or even useful at all. > Marcel: can agents be "stackable", that is, if two agents are registered and > first one doesn't supply an answer, the second will? The default passkey agent (like bt-applet) is not stackable. There should be only one default passkey agent and that one should be provided by the Desktop environment (like GNOME, KDE etc.). However you can have multiple device specific agents for connection wizards or other situations where you expect a PIN request. Regards Marcel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#385857: [Pkg-bluetooth-maintainers] Bug#385857: please upgrade to bluez-utils and bluez-libs 3.4
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/ 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
Bug#385857: [Pkg-bluetooth-maintainers] Bug#385857: please upgrade to bluez-utils and bluez-libs 3.4
Hi Filippo, > > the 3.5 is coming really soon and fixes another couple of rare race > > conditions that can lead to segmentation faults of hcid. The 3.1 version > > is not really suited for daily use. > > allright, I'm going to wait for bluez 3.5 and then package it. should be out this week. If I am not going to be to distracted at the Linux-Kongress. > > > 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. > > 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? > > They are a fully replacement for the ones in the Debian package. That is > > another thing that always needs to be discussed with upstream. > > indeed, this has been discussed extensively in > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=378839 and on bluez-devel > > > > > To install them --enable-pcmciarules is needed and the correct configure > > call. Example is in the README. Otherwise the wrong directory will be > > picked for them. > > okay, thanks. Please test the installation. The current version contains a nasty hack to get them into the right place. 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. Regards Marcel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#385857: [Pkg-bluetooth-maintainers] Bug#385857: please upgrade to bluez-utils and bluez-libs 3.4
Hi, On Mon, Sep 04, 2006 at 12:52:40PM +0200, Marcel Holtmann wrote: > the 3.5 is coming really soon and fixes another couple of rare race > conditions that can lead to segmentation faults of hcid. The 3.1 version > is not really suited for daily use. allright, I'm going to wait for bluez 3.5 and then package it. > > > 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. > > 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. > They are a fully replacement for the ones in the Debian package. That is > another thing that always needs to be discussed with upstream. indeed, this has been discussed extensively in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=378839 and on bluez-devel > > To install them --enable-pcmciarules is needed and the correct configure > call. Example is in the README. Otherwise the wrong directory will be > picked for them. okay, thanks. filippo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#385857: [Pkg-bluetooth-maintainers] Bug#385857: please upgrade to bluez-utils and bluez-libs 3.4
Hi Flavio, > Package: bluez-utils > Version: 3.1-4 > Severity: wishlist > > Yesterday I bought a Bluetooth USB dongle to connect with my mobile > phone, but I had some problems with discovery and sending files from > phone to computer. I'm using bluez-utils and kdebluetooth on Debian > testing/unstable. > > The problem with discovery was the well-known issue with ISCAN, but > after I fixed that I still wasn't able to send files from phone to > computer. Finally I packaged bluez-libs and bluez-utils 3.4 and it > worked at the first try, so I suspect the "couple of issues of the D-Bus > based API" fixed in 3.2, 3.3 and 3.4 are significant after all. the 3.5 is coming really soon and fixes another couple of rare race conditions that can lead to segmentation faults of hcid. The 3.1 version is not really suited for daily use. > 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. 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. > Also note that apparently it is important to remove leftover stuff from > /var/lib/bluetooth/ to fix the ISCAN issue; it is also probably > a good idea to add "discovto 0;" to the default configuration file (see > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=384379). Adding discovto makes a device more insecure. It should go back to non-discoverable mode unless the user configures it otherwise. And removing all files from /var/lib/bluetooth is a really bad idea. You will also remove link keys and the name cache. If you wanna reset the settings then only look at the config files (plural, because some people actually use multiple adapters) in that directory. However I wouldn't advise to touch the configuration storage at all. > Finally, upstream added udev rules for Bluetooth serial PCMCIA cards; I > don't know if these udev rules are useful. They are a fully replacement for the ones in the Debian package. That is another thing that always needs to be discussed with upstream. To install them --enable-pcmciarules is needed and the correct configure call. Example is in the README. Otherwise the wrong directory will be picked for them. > -- System Information: > Debian Release: testing/unstable > APT prefers testing > APT policy: (500, 'testing'), (10, 'unstable') > Architecture: i386 (i686) > Shell: /bin/sh linked to /bin/bash > Kernel: Linux 2.6.17.11-athlon > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) > > Versions of packages bluez-utils depends on: > ii dbus 0.62-4 simple interprocess messaging > syst > ii libbluetooth23.1-1 Library to use the BlueZ Linux > Blu > ii libc62.3.6-15GNU C Library: Shared libraries > ii libdbus-1-2 0.62-4 simple interprocess messaging > syst > ii libusb-0.1-4 2:0.1.12-2 userspace USB programming library > ii lsb-base 3.1-14 Linux Standard Base 3.1 init > scrip > ii makedev 2.3.1-82creates device files in /dev > ii module-init-tools3.2.2-3 tools for managing Linux kernel > mo > ii modutils 2.4.27.0-6 Linux module utilities > ii sysvinit 2.86.ds1-15 System-V-like init utilities > ii udev 0.093-1 /dev/ and hotplug management > daemo > > bluez-utils recommends no packages. > > -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
