Hello,
On 22/07/2025 15:21, Luiz Augusto von Dentz wrote:
Hi Bastien,
On Tue, Jul 22, 2025 at 10:10 AM Bastien Nocera <hadess@xxxxxxxxxx> wrote:
On Tue, 2025-07-22 at 14:26 +0100, Francesco Giancane wrote:
Hello!
On 22/07/2025 13:54, Bastien Nocera wrote:
On Mon, 2025-07-21 at 16:22 +0100, Francesco Giancane wrote:
Hi,
I am posting this patch series to better decouple `bluetoothd`
daemon
and `libbluetooth`, as mentioned in the subject.
I am introducing this change to make new BlueZ more granular.
This will allow more control on which components are actually
selected
to build.
Major use case for this change is fixing circular dependencies
when
bootstrapping new builds where the whole build root is to be
recreated
(e.g. Yocto Project).
In these scenarios, to have Bluetooth support enabled in Python,
`libbluetooth` is required at build time to be present but the
direct
chain of dependencies would require a Python installation
available,
thus introducing circular dependency.
Separating the library and header files from the rest allows
build
systems to break the dependency loop.
FWIW, I'm currently porting bluez to meson (currently stuck on
porting
ell with its gazillion of SSL certificate tests), which would make
python a pre-requirement for bluez (if meson ended up being the
only
build system).
What part of Python itself has Bluetooth support? Wouldn't it also
be
possible to make that part of Python separate so it can be built
after
bluez?
Python uses autoconf to detect compile-time dependencies.
They implemented Bluetooth network management with standard socket()
calls.
This code path is enabled at compile time only if it detects
bluetooth.h
header.
So for python to support Bluetooth in std library, libbluetooth
should
be already deployed.
With this current patch series I posted, you can build a "lite"
version
of bluez to ship just enough
the library and the headers so that python can have bluetooth support
(building a full BlueZ package requires
python too... hence the circular dependency).
Right, so you're trying to do:
- bluez (lib and headers only)
- python (with Bluetooth support)
- bluez (full)
And if meson were the only build system, you'd need to do:
- python (without Bluetooth support)
- bluez (full)
- python (with Bluetooth support)
I guess having a minimal uapi header upstream would allow to do:
- python (with Bluetooth support)
- bluez (full)
+1
Definitely the best option.
I think it might be best to only migrate to the upstream kernel uapi
the minimum needed to build Python with Bluetooth support, and extend
it as needed afterwards.
What sort of Bluetooth support does Python have built-in? I thought
that would use D-Bus like pybluez, etc, but perhaps it has some HCI
and SDP functionality that came built-in with libbluetooth, but its
usability is very limited without the daemon, in fact it probably not
really recommended to do HCI or SDP on the application side nowadays
since we now have management interface that abstract HCI and SDP is
sort of legacy with LE Audio catching up with BR/EDR that will
probably be deprecated at some point, so perhaps we shall work with
Python folks to drop the usage of libbluetooth completely once we have
the UAPI headers.
So I am no Bluetooth expert (not at this level). I was helping a
colleague running
some Bluetooth applications on an embedded chip using Python and
basically all of these
scripts were broken because of missing HAVE_BLUETOOTH_BLUETOOTH_H symbol
(would be defined
with libbluetooth in place). Some time has passed to if details are
required it may take some time from
me to recover them, but i can do. I clearly recall we were using
bluetoothd in tandem with this python package
(which allegedly, required built-in bluetooth support to be enabled).
For reference:
https://github.com/python/cpython/blob/main/Modules/socketmodule.h#L116
https://github.com/python/cpython/blob/main/Modules/socketmodule.h#L282
And perhaps more interestingly:
https://github.com/python/cpython/blob/main/Modules/socketmodule.c
In the short-term, why not apply your bluez patches to your bluetoothd
recipe rather than upstream? That should also motivate developers to
land the "correct" fix upstream ;)
Yeah, going with intermediate solution will sort of introduce a new
dependency in the form of lib only support which will serve as excuse
not to adopt UAPI as soon as they are available.
Got it, let's go with the upstream approach then. I do not see any
blocker besides kernel
discussions here. I am fine deprecating altogether the libbluetooth
intermediate effort.
On the other side, since you mentioned, I can check which specific
python libraries were using
libbluetooth and the above code path, to see if they were using already
the legacy approach or
if it is however something that must be supported in Python.
Thanks!
Cheers
Francesco
`--enable-bluetoothd` flag is added to the `configure` script and
it is keeping the same behavior as other flags.
Francesco Giancane (3):
configure.ac: introduce `--enable-bluetoothd` flag
Makefile.am: build `bluetoothd` if enabled
README: document `--enable-bluetoothd` flag
Makefile.am | 8 ++++++++
README | 14 ++++++++++++++
configure.ac | 4 ++++
3 files changed, 26 insertions(+)
