On 22/12/19 8:10 pm, Stefan Seyfried wrote:
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 :-)
Stefan Many thanks for your efforts, they are really appreciated. Un-deprecating rfcomm upstream would be such a great result for many frustrated users. A further issue. I have UnitedRemote Server installed on my netbook to allow remote control of the moving map software from an Android phone via bluetooth. I run bluetoothd in compatibility mode (/usr/lib/bluetooth/bluetoothd --compat) to force it to create the required Service Discovery Protocol socket (/run/sdp); and all is good. But I suspect compatibility mode will cease be available after the proposed removal of /usr/bin/sdptool; could you please confirm whether this is the case. Obviously I'm concerned the creation of /run/sdp, or its successor, will become quite complex/difficult for a non-expert. I don't see that the suggested "bluetoothd together with bluetoothctl" will provide an alternative in this case so the answer may be to try and adapt one of the bluez test examples; maybe example-gatt-server or example-advertisement. But seriously. Do you think there is a case for un-deprecating sdptool as well? Graeme -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org