-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 2019-12-17 at 15:16 +0100, Stefan Seyfried wrote: ...

I have listed the replacements as far as I know them above below the tools, other tools (or snippets for writing your own) are in the bluez-test package, which consists mostly of small python demo applications.

On IRC someone just said "bluez-devel has been removed from the python3 build". Is this related? :-? - -- Cheers, Carlos E. R. (from openSUSE 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXfjl5xwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfV7NcAoI8aQif+VNiIK5GZargk k7rqSsciAJ0Z6hSYVNE1d3L/Kv25duvUqqj6+A== =IFgX -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 18/12/2019 08.49, Stefan Seyfried wrote:

Am 17.12.19 um 15:27 schrieb Carlos E. R.:

...

On Tuesday, 2019-12-17 at 15:16 +0100, Stefan Seyfried wrote:

...

...

I have listed the replacements as far as I know them above below the tools, other tools (or snippets for writing your own) are in the bluez-test package, which consists mostly of small python demo applications.

On IRC someone just said "bluez-devel has been removed from the python3 build". Is this related? :-?

I guess you have to ask "someone".

Sorry, it is that "someone" who is asking openSUSE. He found that it (b-d in python3) has been removed, and the question is if that removal is related to this removal commented in the OP, or is unrelated. - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXfoJDwAKCRC1MxgcbY1H 1XPfAKCYNTFPKSSi8lUdx05WdiRzzDvjagCfcj2+SFU8tweTB6bg7jAnL1aPxMo= =da6f -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 18/12/2019 13.33, Stefan Seyfried wrote:

Am 18.12.19 um 12:10 schrieb Carlos E. R.:

...

On 18/12/2019 08.49, Stefan Seyfried wrote:

...

Am 17.12.19 um 15:27 schrieb Carlos E. R.:

...

On Tuesday, 2019-12-17 at 15:16 +0100, Stefan Seyfried wrote:

...

...

I have listed the replacements as far as I know them above below the tools, other tools (or snippets for writing your own) are in the bluez-test package, which consists mostly of small python demo applications.

On IRC someone just said "bluez-devel has been removed from the python3 build". Is this related? :-?

...

I guess you have to ask "someone".

Sorry, it is that "someone" who is asking openSUSE.

He found that it (b-d in python3) has been removed, and the question is if that removal is related to this removal commented in the OP, or is unrelated.

I have no idea why python3 would ever have depended on bluez-devel, but I don't think this is related, but just "somebody" cleaned out old cruft from python3 spec files.

see the $SUBJECT: nothing about bluez-devel, just getting rid of deprecated tools.

Ok, thanks! - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXfo50AAKCRC1MxgcbY1H 1Uw3AJ9F08OTG8Ku9+/jI+Ec5TddSGLtiACgmPDw2GBvWvNV/NnbKvkU5fuA6i0= =lQju -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 19/12/2019 18.26, Stefan Brüns wrote:

On Mittwoch, 18. Dezember 2019 13:33:33 CET Stefan Seyfried wrote:

...

Am 18.12.19 um 12:10 schrieb Carlos E. R.:

...

On 18/12/2019 08.49, Stefan Seyfried wrote: He found that it (b-d in python3) has been removed, and the question is if that removal is related to this removal commented in the OP, or is unrelated.

I have no idea why python3 would ever have depended on bluez-devel, but I don't think this is related, but just "somebody" cleaned out old cruft from python3 spec files.

see the $SUBJECT: nothing about bluez-devel, just getting rid of deprecated tools.

Just to shed some light on why Python requires bluez-devel:

Pythons 'socket' module has optional support for the AF_BLUETOOTH protocol family, but it is only enabled when bluez-devel is available during build.

As socket is a dependency of many other modules it is built as part of python3-base. python3-base is a build dependency of many other packages, probably 2/3rd of all TW packages depend on it (directly or indirectly). Most importantly, python3-base is also a build dependency of bluez.

The bluez-devel BuildRequires was moved from python3 to python3-base to make AF_BLUETOOTH available in pythons socket, but as it introduces a build loop it was removed again.

Ah, thanks! I hope the IRC person that initially asked reads this. He is not online now. - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXfu+hAAKCRC1MxgcbY1H 1WXVAJ9M8u1jhkUY12TqbIMeJiakbZtzTwCfXAmQJu5sW6ysq/AYW7Dc/3L4ZHI= =7CbD -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tue, 17 Dec 2019 15:16:38 +0100, Stefan Seyfried wrote:

Hi Jiri,

I'm writing the below hints mostly from reading the tool's manpages, because I have not used them ever (and I have done some debugging on bluetooth issues during the last 15 years... ;-)

I was scanning a README that I once wrote for myself to get my phone connected. Taking this as a starting point ...

Am 17.12.19 um 14:36 schrieb Jiri Slaby:

...

On 16. 12. 19, 15:39, Stefan Seyfried wrote: : :

...

/usr/bin/hciattach

A tool to connect serial UART Bluetooth devices. Newer tool is btattach.

Clear and mostly obvious. $ hciattach help hciattach - HCI UART driver initialization utility Usage: hciattach [-n] [-p] [-b] [-r] [-t timeout] [-s initial_speed] <tty> [speed] [flow|noflow] [sleep|nosleep] [bdaddr] hciattach -l $ btattach --help btattach - Bluetooth serial utility Usage: btattach [options] options: -B, --bredr <device> Attach Primary controller -A, --amp <device> Attach AMP controller -P, --protocol <proto> Specify protocol type -S, --speed <baudrate> Specify which baudrate to use -N, --noflowctl Disable flow control -h, --help Show help options

...

...

/usr/bin/hciconfig /usr/bin/hcitool /usr/bin/sdptool

bluetoothd together with bluetoothctl

Is there a manual describing how to convert scripts using the old tools to describing how that would be done in the new? # hciconfig hci0 up What would I need to do to use the new tools?

...

...

/usr/bin/hcidump

btmon (hcidump actually is the one that needs security patches that upstream no longer wants to include)

Clear

...

...

/usr/bin/rfcomm

bluetoothd together with bluetoothctl

Same as with the other tools: is there a walkthrough for conversion?

...

...

In the not too far future, the bluez-deprecated package will be dropped and bluez will be built without "--enable-deprecated". If I had to guess now, I would say that "not too far future" means "end of 2020".

Perhaps you can also point us to some document defining in favor of what they are deprecated. I.e. what we are supposed to use instead of the above?

I have listed the replacements as far as I know them above below the tools, other tools (or snippets for writing your own) are in the bluez-test package, which consists mostly of small python demo applications.

Basically the upstream reasoning for deprecating these tools is that bluetoothd as the central service is handling all this in a coordinated way and should be used (vie bluetoothctl or desktop applets) to perform the tasks that these tools did. As an example, a manual "hcitool scan" did interfere with things bluetoothd does and settings done with "hciconfig" were not persisted anywhere (and bluetoothd did not know about them and thus did not work correctly), so this is why these tools were deprecated. At least that's how I understood it :-)

I have been using bluetoothctl for almost all my configuration and debugging tasks and could perform all tasks that I needed. It's even better than using a desktop applet, since I can copy and paste the bluetoothctl commands easily into a HOWTO or a bug report ;-)

Have fun,

-- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.31 porting perl5 on HP-UX, AIX, and Linux https://useplaintext.email https://tux.nl http://www.test-smoke.org http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/

On 18/12/2019 14.06, Stefan Seyfried wrote:

Not that I know of.

Do you know hardware (which can still be bought) that talks raw rfcomm so I could test?

All the common stuff (ppp over rfcomm to a phone or such) is handled by NetworkManager / ModemManager and similar tools.

~4 years ago, I used raw rfcomm to have my perl scripts communicate with the Lego Mindstorms (I think 2nd edition) - not sure what the current version uses but it probably still is bluetooth. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

I regularly use an i-Blue 747A+ Bluetooth GPS Trip Recorder. It is a GPS data receiver that provides both bluetooth and USB connectivity. It can also store the data for later download, via USB only. I'm not sure the 747A+ is still sold but other brands based on the same MediaTek MTK chipset, and with similar functionality, are available. e.g. the Qstarz GPS Datalogger BT-Q1000XT. These device are quite common. For my use case, the 747A+ provides GPS data via bluetooth to a Netbook running a moving map program (OziExplorer running under Wine). I use a bash script, triggered by udev, to bind the 747A+ to /dev/rfcomm, which is soft linked with the COM port used by OziExplorer. The set up has worked well for many years. My udev script first runs "/usr/bin/hciconfig hci0 up" to ensure the controller is available. It appears /usr/bin/hciconfig can be replaced by echoing commands to bluetoothctl. e.g. " echo -e "trust $MAC\nconnect $MAC\nquit" | bluetoothctl". A workable kludge I guess. However, finding a replacement for the primary command, "/usr/bin/rfcomm bind /dev/rfcomm0 <GPS>", is another story. In an earlier reply Stefan indicated that /usr/bin/rfcomm can also be replaced by 'bluetoothd together with bluetoothctl'. I am not skilled with bluetooth and the bluetoothctl help is pretty sparse but I can't find anything there to set up /dev/rfcomm and bind a device to it. An example would be very helpful. Google failed me as well. The stuff I could find suggests it must now be set up via dbus. But this is not straight forward and one of the bluez devs commented that it would be better for non-experts to try the Python based Blue Dot library. I had a play with the Blue Dot library but it simply throws the exception "AttributeError: module 'socket' has no attribute 'AF_BLUETOOTH'", which is not surprising given the earlier comment that AF_BLUETOOTH was removed from Python on openSUSE. So, in summary, yes there are users of this stuff; there is a workable alternative to at least some of the hcixxx commands; but a replacement for /usr/bin/rfcomm is problematic. Graeme Blackman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 21.12.19 um 10:08 schrieb Stefan Seyfried:

[...]

I have now ordered a Kit containing amongst others a HC-05 serial bluetooth module for Arduino&co, so I guess I will be able to verify rfcomm soon (unfortunately, all my phones only support NAP/PANU but not DUN profile). -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hi all, I have had a closer look at various code bases, including bluez git, pybluez, blueman. Am 21.12.19 um 14:25 schrieb Stefan Brüns:

On Samstag, 21. Dezember 2019 10:08:13 CET Stefan Seyfried wrote:

...

Am 21.12.19 um 07:19 schrieb Graeme Blackman:

...

I had a play with the Blue Dot library but it simply throws the exception "AttributeError: module 'socket' has no attribute 'AF_BLUETOOTH'", which is not surprising given the earlier comment that AF_BLUETOOTH was removed from Python on openSUSE.

I don't think anything using socket() with AF_BLUETOOTH is advisable.

bluez-test package contains /usr/lib64/bluez/test/test-sap-server that does some RFCOMM stuff, it is using python-pybluez (which apparently does not need AF_BLUETOOTH).

python-pybluez wraps the raw socket itself [1], so it does not depend on AF_BLUETOOTH support in pythons core socket module.

...and this is basically reimplementing the functionality of the rfcomm binary... ;-) Blueman is also more or less doing the same. So if the solution for "what to use instead of /usr/bin/rfcomm" is "implement the same funcitonality in $OTHER_LANGUAGE", then keeping the rfcomm binary seems to be the best choice. I have inquired upstream about this and asked to un-deprecate rfcomm. Let's see what comes out of this discussion. If there is no resolution, I can still patch bluez to "un-deprecate" rfcomm for openSUSE :-) Have fun, seife -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 23.12.19 um 05:47 schrieb Graeme Blackman:

Do you think there is a case for un-deprecating sdptool as well?

No. I think this "UnitedRemote Server" should just register itself properly to bluetoothd. cf /usr/share/doc/packages/bluez/dbus-apis/profile-api.txt BlueZ D-Bus Profile API description *********************************** Profile Manager hierarchy ========================= Service org.bluez Interface org.bluez.ProfileManager1 Object path /org/bluez void RegisterProfile(object profile, string uuid, dict options) This registers a profile implementation. This is not new high-tech stuff. I has been around and recommended since bluez-5.0, which is now 5 years old. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hi Stefan Thanks again for following up with the bluez devs. Given the lack of an alternative to /dev/rfcommX, is it still your intention to patch bluez to "un-deprecate" rfcomm for openSUSE? Best regards Graeme On 4/1/20 11:09 pm, Stefan Seyfried wrote:

Hi Graeme.

Am 23.12.19 um 05:47 schrieb Graeme Blackman:

...

On 22/12/19 8:10 pm, Stefan Seyfried wrote:

...

I have inquired upstream about this and asked to un-deprecate rfcomm.

Let's see what comes out of this discussion. If there is no resolution, I can still patch bluez to "un-deprecate" rfcomm for openSUSE :-) Many thanks for your efforts, they are really appreciated. Un-deprecating rfcomm upstream would be such a great result for many frustrated users. I guess that this (upstream bluez un-deprecating rfcomm tool) will not happen: I have been pointed to the doc/profile-api.txt and after investigating I have been able to use it to create both a SPP server and a SPP client, using the examples fromhttps://ukbaz.github.io/howto/AppInventor.html (for the SPP server) andhttps://github.com/tonyespy/bluez5-spp-example (for both SPP server and client). It does not create /dev/rfcommX devices, though.

Best regards,

Stefan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 17. 12. 19, 15:16, Stefan Seyfried wrote:

Hi Jiri,

...

...

/usr/bin/hciconfig /usr/bin/hcitool /usr/bin/sdptool

bluetoothd together with bluetoothctl

...

...

/usr/bin/hcidump

btmon (hcidump actually is the one that needs security patches that upstream no longer wants to include) Thanks!

-- js suse labs -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org