Bug#336777: bluez-utils: New version does not want me to connect anymore
severity 33677 important thanks On Tue, 2005-11-01 at 14:35 +0100, Laurent CARON wrote: > Package: bluez-utils > Version: 2.19-1 > Severity: grave > Justification: renders package unusable > > > After having upgraded to new bluez-utils i'm unable to connect my phone > (Ericsson T630) anymore. > > I can connect by deleting association and recreating *each time*. > > Downgrading to the stable version solves this problem. We're working on getting the latest upstream release in, which I hope will fix this problem. -- Edd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#338260: bluez-utils: new version available - doesn't work with Logitech MX5000
On Tue, 2005-11-08 at 21:50 -0500, Martin Stolle wrote: > Package: bluez-utils > Version: 2.19-1 > Severity: normal > > > Hello, there's now a much more recent version available (2.22) which > adds support for more Logitech Bluetooth keyboards, presumable MX5000 > too. > > Please update the package to the latest version. We're working on it. thanks -- Edd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#330598: bluez-utils: Reconnecting pand with auth enable broken in 2.19-1
Thanks for reporting this bug. We are working on getting the latest upstream into Debian, which I hope will fix this. On Wed, 2005-09-28 at 22:39 +0200, Arne Ahrend wrote: > Package: bluez-utils > Version: 2.15-1 > Severity: important > > Reconnecting pand to the access point using auth enable and encrypt > enable in /etc/bluetooth/hcid.conf does not work with the testing > version, downgrading to the stable version resolves the issue. > > I noticed that the new version takes a more structured management > approach to the link key files. The bug only affects reconnecting. If I > delete the link key files, the new version properly uses the pin to > connect to the access point for the first time. > > For sake of completeness I should mention that I use a quick and dirty > custom shell script to supply the pin, it is attached below. > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#338743: [bluez-utils #338743] More info
Can you verify the MAKEDEV constructs the appropriate devices exactly as the mknod from the postinst does? This was the reason I didn't use MAKEDEV in the first instance, albeit some time ago. On Fri, 2005-12-23 at 09:41 +0100, Alexis Sukrieh wrote: > tags 338743 + patch > thanks > > * Marco d'Itri ([EMAIL PROTECTED]) disait : > > cd /dev && ./MAKEDEV bluetooth > > > > less /sbin/MAKEDEV > > Thanks, here is attached a patch for the postinst script. > I plan to make a sponsored NMU for closing this RC bug in bluez-utils' > maintainer does not apply it. > > Best regards, > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#330071: hciconfig shows no devices (whereas, 2.6.8-2-686-smp does)
On Fri, 2005-09-30 at 21:57 -0700, Jurij Smakov wrote: > [CCing Edd Dumbill, bluez-utils maintainer] > > Hi Edd, > > Could you please have a look at bug #330071, filed against kernel? The > report is about hciconfig not showing the devices on 2.6.12 kernel, while > 2.6.8 appears to be fine. Do you have any ideas about what is going on? Not from the debug information sent, alas. The best thing to do would be to include the output of 'hciconfig -a' with the working kernel on the bug report, and refer it to the bluez-users mailing list (see bluez.org). I do not myself have enough kernel expertise to suggest anything here. -- Edd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#293210: bluez-bcm203x firmware loader depends on non-free firmware
Josh, thanks for filing this. It is as you say good to have it out there. My question is this: why should this firmware loader be any different than the kernel? It is required only under kernel 2.4, and performs the same function as the bcm203x module in kernel 2.6. I can see no reason for not applying exactly the same practice as Debian does to the kernel. I am not a lawyer, nor do I have enough spare time to sink into argument about this. My guiding principle will be to follow what happens to the kernel here unless I am persuaded convincingly by my fellow developers or project policy otherwise. regards -- Edd signature.asc Description: This is a digitally signed message part
Bug#293210: bluez-bcm203x bug
On Sat, 2005-02-05 at 17:38 +0100, Bas Zoetekouw wrote: > Hi! > > IMO the situation for this package is different from the kernel's. > > In the case of the kernel, it functions completely ok without any of > the non-free firmwares; those only provide additional functionality. > > Bluez-bcm203x's only function otoh, is to load the non-free firmware. > In this aspect, it is no different than a installer packages (flash, > acroread, msttcorefonts, etc), and therefor should be in cntrib. The situation is slightly more subtle than that. bluez-bcm203x is part of the same source package as bluez-utils, which are free software and do provide a considerable amount of functionality. So moving the bcm203x loader to contrib can't be done simply, as it would move all Bluetooth basic support there. Also, by your argument all I'd have to do would be to move the firmware loader program into bluez-utils rather than have it as a separate package, and I'd satisfy your justification for the kernel not being in contrib. -- Edd signature.asc Description: This is a digitally signed message part
Bug#293210: bluez-bcm203x bug
On Sat, 2005-02-05 at 19:20 +0100, Frank Lichtenheld wrote: > Hmm, it is possible to only move one binary package to contrib and there > are examples for this in the archive. I don't know if this is > encouraged, though. Well, I'll give it a try then. I've prepared a new package whose Section is contrib/admin, and I'll upload today. That would be the ideal solution, if it works. -- Edd signature.asc Description: This is a digitally signed message part
Bug#239820: bluez-utils: also a problem if you do have X
On Sat, 2005-02-05 at 15:53 +, Franck Arnaud wrote: > This issue is also a problem if you do have X. I have a machine with > a flash disk and a minimal X setup, and bluez-pin still wants 10MB > of disk space (which is a large part of my available disk space) to > install all the extra rubbish it depends on. That to display one > dialog box with one field, this is bloatware on a fairly major > scale. > > Is something being done about this issue? If not, I think I will > have to volunteer. Thanks. No, nothing is currently being done. Your volunteering would be great! -- Edd signature.asc Description: This is a digitally signed message part
Bug#285533: bluez-hcidump: FTBFS (amd64/gcc-4.0): static declaration of 'sdp_siz_idx_lookup_table' follows non-static declaration
tags 285533 fixed-upstream thanks This has been fixed in upstream's CVS and will be in the next release. The upstream maintainer didn't use your patch, I'm afraid, but did other changes. Thanks for your contribution. Edd. On Mon, 2004-12-13 at 22:56 +0100, Andreas Jochens wrote: > Package: bluez-hcidump > Severity: normal > Tags: patch > > When building 'bluez-hcidump' on amd64 with gcc-4.0, > I get the following error: signature.asc Description: This is a digitally signed message part
Bug#308207: bluez-utils: `bluepin` does not start - appears to be needing a "gtk" library
On Sun, 2005-05-08 at 22:15 +0200, Jacob Sparre Andersen wrote: > Edd Dumbill wrote: > > On Sun, 2005-05-08 at 21:34 +0200, Jacob Sparre Andersen > > wrote: > > > No, this is because you need to run 'xhost +' or similar > > on your system to allow the bluepin helper to access the > > display. > > No! If that was the case, then I wouldn't be able to launch > a new xterm from the same command-line - which I was. > > But it may be that the problem then is somewhere in the > libraries `bluepin` uses. No, because bluepin doesn't work in the same XAUTHORITY context, it tries to figure it out from scratch in rather a heavy-handed way. This is why I recommend bluez-pin. I kept bluepin around for those users who started off using it when it was the only option. Edd. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#311743: Coming soon
Just to let folks know this will be coming soon. thanks for your patience -- Edd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#285533: bluez-hcidump: FTBFS (amd64/gcc-4.0): static declaration of 'sdp_siz_idx_lookup_table' follows non-static declaration
On Sun, 2005-07-17 at 00:47 -0700, Steve Langasek wrote: > Hi Edd, > > > This has been fixed in upstream's CVS and will be in the next release. > > That was five months ago, and gcc-4.0 is now the default compiler in etch. > When could we expect this new upstream release to be uploaded to Debian? I uploaded it yesterday. I've not tried to compile it on amd64 though myself. There doesn't seem to be amd64 autobuilder yet. -- Edd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#317986: bluez-utils: device name defaults to 'BlueZ' even if configured in hcid.conf
severity 317986 normal
tags 317986 sarge moreinfo
thanks
On Tue, 2005-07-12 at 20:12 +0200, Benoit Panizzon wrote:
> Probably something get's wrong while the device is initialized...
>
> I have /etc/bluetooth/hcid.conf
>
> # Default settings for HCI devices
> device {
> # Local device name
> # %d - device id
> # %h - host name
> name "%h-%d";
>
> etc...
>
> But when I do:
> # hciconfig hci0 name
> hci0: Type: USB
> BD Address: 00:10:60:A8:97:82 ACL MTU: 192:8 SCO MTU: 64:8
> Name: 'BlueZ'
>
> The Name is not set. Causing confustion if you have multipe 'BlueZ' computers
> within range :-)
>
> This must have changes somewhen as I rememver several months ago the device
> name was set correctly.
You are the first to report this, and the package has been stable a long
time. I am wondering if this isn't a problem your end.
If possible, can you restart your system and confirm it still happens.
Also please attach your entire hcid.conf file. If you don't want it to
get in the bug system, feel free to send it to me privately.
Also, you did not send the entire output of hciconfig. Please send the
output of 'hciconfig -a'
cheers
-- Edd
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#302990: bluez-firmware: Doesn't load firmware into device with current hotplug, udev and kernel 2.6.11
reassign 302990 udev thanks On Sun, 2005-04-03 at 17:57 -0400, Ron Murray wrote: > > Problem seems to involve udev, as temporarily replacing > "/sbin/udevsend" in /proc/sys/kernel/hotplug with "/sbin/hotplug", > then plugging dongle into USB port allows it to work. I think therefore this is a udev bug, as nothing has changed with BlueZ. -- Edd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#255691: Is this still a problem for you?
Still suffering from this? I've had no other reports of it http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=255691 -- Edd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#239820: bluez-utils: also a problem if you do have X
On Sat, 2005-08-13 at 19:22 +0200, Miernik wrote: > Any progress on this? It's very much wanted to fix this terrible > bloatware overkill. No, none yet. Now would be a good time though. I'll put it on my TODO list, but I'd be very happy if somebody could step up. It's as simple as making a bluez-pinhelper virtual package, provided by the existing bluez-pin package, and creating a simple little pinhelper that just echoes the contents of /etc/bluetooth/pin in a package like bluez-pinhelper-static, which also provies bluez-pinhelper. Then bluez-utils need only depend on the virtual package. Some juggling may be required to ensure that by default most people still get the graphical install as expected. -- Edd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#323365: bluez-utils 2.19-1 not in Sarge security updates?
On Sun, 2005-09-25 at 18:06 -0400, William Ballard wrote: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=323365 > > Why is this grave security bugfix not in Sarge security updates, more > than a month later? I know there's a "good reason," but in my few years > of using Debian I have always run unstable. It is, version 2.15-1.1, you just missed it. We don't upload new upstream versions to stable to fix security holes. Where we can we just backport the fix. This is so as not to cause knock-on problems introduced in new versions. In the case of bluez-utils, this is exactly what was done -- see http://packages.debian.org/stable/admin/bluez-utils http://packages.debian.org/changelogs/pool/main/b/bluez-utils/bluez-utils_2.15-1.1/changelog I would not have closed the bug if the fix hadn't gone in. -- Edd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#115763: Network Sync does not work
tags 115763 patch tags 288820 patch thanks This patch from gentoo makes Network Sync work nicely for gnome-pilot-2.0.13 https://bugs.gentoo.org/show_bug.cgi?id=88511 --> https://bugs.gentoo.org/attachment.cgi?id=55793 -- Edd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#297020: dbus-1-dev: Version 0.23.2 breaks API
Package: dbus-1-dev Version: 0.23.2-2 Severity: grave Version 0.23.2 removes a function from the API without changing the SONAME of the library. In particular, my package bluez-utils is caused not to build from source by this change. bluez-utils-2.15/hcid/dbus.c:75: undefined reference to `dbus_pending_call_get_reply' This function seems to have disappeared. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (101, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.10-rc3 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Versions of packages dbus-1-dev depends on: ii dbus-10.23.2-2 simple interprocess messaging syst ii pkg-config0.15.0-4 Manage compile and link flags for -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#355322: Package should be "arch: all", not "any"
On Sat, 2006-03-04 at 22:56 +, Martin Michlmayr wrote: > This package is "arch: any" but should be "arch: all" since it > contains no architecture specific code. (Or maybe it's time to remove > the package?). It really ought to be removed now. I was actually under the impression it had been removed already! -- Edd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#355497: [Pkg-bluetooth-maintainers] Bug#355497: bluez-utils: hid2hci --tohid does not work
On Mon, 2006-03-06 at 03:47 +0100, Mourad De Clerck wrote: > according to the manpage, hid2hci is used to switch HID proxy bluetooth > dongle > into the HCI mode and back. The bluetooth initscript tries to make use of it > on stop/shutdown. > > However, it doesn't seem to work for me: my symptom is that I have no way of > typing on my system, when I reboot after booting first in Debian. The BIOS or > the GRUB menu are inaccessible if I last booted in Debian. > ... > So bottom line is: switching from HID to HCI works, switching back doesn't > (and never has I might add). For the record: my keyboard is a Logitech DiNovo > Media Desktop with an MX900 BT mouse. I notice Ubuntu have disabled the hid2hci switching completely. It works fine on my DLink dongle, but it may not be a good thing to have enabled by default. We should probably make this configurable and switch it off by default. -- Edd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#237386: situation changed with libopenobex
On Thu, 2006-02-09 at 23:55 +0100, Hendrik Sattler wrote: > retitle 237386 please update to openobex-1.1 > thanks > > Hi, > > SF has openobex-1.1 available and this version is NEEDED for USB device > support with obexftp-0.19 (And I really would like to package that). > > The new version depends on a libusb version that is already in Sid, so it > should compile just fine. > > If you need any help on this, please tell me. Actually help would be very welcome, I'm very short on time. Do you want to adopt libopenobex or at least co-maintain? -- Edd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#359003: [Pkg-bluetooth-maintainers] Bug#359003: bluez-utils: udev script missing
Please include the output of lsusb -v so we can see the make and model of your dongle On Sat, 2006-03-25 at 21:04 +0100, Hadmut Danisch wrote: > Package: bluez-utils > Version: 2.25-1 > Severity: normal > > Hi, > > when plugging in a USB bluetooth dongle in a running linux system the > bluetooth drivers do not recognize the dongle. I need to call > /etc/init.d/bluez-utils restart to make the dongle work. > > bluez-utils should come with an appropriate udev script which > automatically restarts the bluetooth utils (or does whatever needs to > be done) automatically when a USB dongle is inserted or removed. > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#359003: [Pkg-bluetooth-maintainers] Bug#359003: bluez-utils: udev script missing
On Sun, 2006-03-26 at 10:10 +0200, Hadmut Danisch wrote: > > However, wouldn't it be easier to just take the Vendor/Product id > list > from the driver software? If the dongle driver can use it, there must > be > a list of recognized dongles (or Vendor/Product ids). Why not use > that > already existing list? You're seeing some new bug, I think. For years the dongle will be initialised without the need for a restart. It's not a udev issue, it's hcid in all likelihood. -- Edd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
