Hi Colin,
> > that is exactly how it works and we can't use signal. Even directed
> > signal are not working since the method call into the agent has to
> > return the result or an error.
> >
> > What problem do you guys actually have with this? The agent inside
> > bluez-gnome is verifying that t
Hi Colin,
> > As far as I can tell, BlueZ agents work like this:
> >
> > * the agent (a UI process run by a user) calls a method on the hci daemon
> > (run
> > by root) and passes in its unique name and its (arbitrary) object path
> > * later, the hci daemon calls a method on the agent
> >
> > s
Hi Ludovic,
> I only have "Preferences" and "About" menu entries. I would like to also
> have a "quit" or "remove" menu option to be able to stop the execution
> of bluetooth-applet
use the session preferences for that.
Regards
Marcel
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a su
Hi Hendrik,
> > this is a bluez-utils-2.x config file and simply outdated. Check the
> > source code for the latest one.
>
> The problem is not that the message does not arrive at hcid. If that is the
> problem, setting mode to off would also not work but it does.
> Only "connectable" and "disc
Hi Hendrik,
> > > > > Beside that, running the dbus command suggested in this bug report
> > > > > works, too. It should be noted, though, that you have to be root.
> > > >
> > > > No. You have to be console user (or root).
> > >
> > > I cite from dbus policy that I somehow just don't get (too man
Hi Hendrik,
> > > Beside that, running the dbus command suggested in this bug report works,
> > > too. It should be noted, though, that you have to be root.
> >
> > No. You have to be console user (or root).
>
> I cite from dbus policy that I somehow just don't get (too many english words
> are
Hi Hendrik,
> > > * plugging the dongle in and then chaning to "connectable" may be too
> > > late Practically the same thing as the default from above.
> >
> > This is why we go back to non-discoverable after 180 seconds by default.
> >
> > Supporting these kind of strange setting would also mean
Hi Hendrik,
> > > That is currently not the case because the bluetooth guys change stuff
> > > but the user frontends do catch up a bit late. Just remember the passkey
> > > situation and this is pretty much the same. It probably gets solved in
> > > the long run but that's a strange idea of devel
Hi Hendrik,
> > > Note that deleting the "config" file in /var/lib/bluetooth is an
> > > essential part of the solution.
> >
> > this is a big _NO_. Don't mess with the configuration storage directly.
> > The configuration storage has priority over the hcid.conf file and this
> > is meant to be th
Hi Filippo,
> > > Yes, maybe correct grammatical mistakes if present.
> > > Note that deleting the "config" file in /var/lib/bluetooth is an
> > > essential
> > > part of the solution.
> >
> > this is a big _NO_. Don't mess with the configuration storage directly.
> > The configuration storage
Hi Hendrik,
> > > I am not sure why SCAN_INQUIRY is not set in discovto is not 0 (see
> > > hcid/main.c:295). This is probably to not make it discoverable after
> > > plugging the bt dongle in and thus correct behaviour. However, I do not
> > > know of any user program that can actually handle tha
Hi Per,
> If you have bluez-passkey-gnome installed, you get a tray icon for it
> even if you don't have any bluetooth hardware. This is a bit
> annoying. If it was only shown when bluetooth was actually
> *available*, we would be able to add bluez-passkey-gnome to the
> gnome-desktop task and eve
Hi Martin,
> Package: bluez-hcidump
> Version: 1.31-1
> Severity: serious
>
> This package fails to build in unstable:
>
> > Automatic build of bluez-hcidump_1.31-1 on coconut0 by sbuild/ia64 0.49
> ...
> > cc -DHAVE_CONFIG_H -I. -I. -I.. -g -Wall -O2 -D_FORTIFY_SOURCE=2 -c
> > lmp.c
> > cc
Hi Filippo,
> > In most cases, this is just a minor bug. At least having a default pin
> > and 'pairing multi' on by default are much bigger issues, but it's a
> > security related deviation from upstream. I would like to see this fixed.
>
> From what I can tell, when the user reaches the point
Hi Filippo,
> > although as KDE user, I am not fully happy about that, the ITP for
> > bluez-gnome
> > (see #387923) also solves #382771. The BTS does not allow to express this,
> > AFAIK, that's why I send this message...
>
> indeed, thanks for pointing that out, although I'm in the process o
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.
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
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/un
Hi Alexander,
> Package: bluez-utils
> Version: 3.1-4
> Severity: wishlist
>
> Whilst trying to configure a BNEP network I found my friends USB dongle had a
> wierd hardware address of
> 11:11:11:11:11:11. Reading around it turns out this is what happens when the
> device has no onboard EEPRO
Hi Filippo,
> > > > > > I've updated README.Debian accordingly to your input, it is
> > > > > > available at
> > > > > > http://svn.debian.org/wsvn/pkg-bluetooth/bluez-utils/trunk/debian/README.Debian?op=file&rev=0&sc=0
> > > > > > do you mind having a look and see if it answers your question
>
Hi Marc,
> > > > I've updated README.Debian accordingly to your input, it is available at
> > > > http://svn.debian.org/wsvn/pkg-bluetooth/bluez-utils/trunk/debian/README.Debian?op=file&rev=0&sc=0
> > > > do you mind having a look and see if it answers your question and/or it
> > > > is
> > > > l
Hi,
> > > PHYSDEVPATH and the 'device' link are both deprecated and will go away
> > > some day in the future, you better pass the values you want to use in
> > > your script down from udev with $sysfs{}. That is not dependent on a
> > > specific order of devices in sysfs.
>
> > I've attached wor
Hi Samuel,
> > of course it compiles fine, because it is all simple C code. However
> > without the Bluetooth subsystem of the Linux kernel it is totally
> > useless.
>
> Ok, but when BSD and the Hurd will have bluetooth drivers, it _will_ be
> useful.
only if they follow the Linux kernel interf
Hi Samuel,
> > > > > > bluez-libs currently FTBFS on hurd-i386 and kfreebsd-* just because
> > > > > > it
> > > > > > uses a non-standard errno code EBADRQC.
> > > > > >
> > > > > > I'm not sure about the right way to go: should bluez-libs, for
> > > > > > portability reasons, use another error
Hi Filippo,
> > > > bluez-libs currently FTBFS on hurd-i386 and kfreebsd-* just because it
> > > > uses a non-standard errno code EBADRQC.
> > > >
> > > > I'm not sure about the right way to go: should bluez-libs, for
> > > > portability reasons, use another error code, or should the Hurd and BSD
Hi Filippo,
> > > comments?
> >
> > check for EOPNOTSUPP error code and only then print this error.
>
> allright, I fixed this with the attached patch
the patch has been applied to the CVS now. Thanks.
Regards
Marcel
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsub
Hi Filippo,
> > When the 'rfcomm' kernel module isn't compiled with CONFIG_BT_RFCOMM_TTY
> > enabled, 'rfcomm bind' will fail with an obscure error message, "Can't
> > create device: Operation not supported". It does this when it's trying to
> > bind to a device in /dev.
> >
> > Could this be ch
27 matches
Mail list logo
