Bug#597586: unblock: bluez/4.70-1
Nobuhiro Iwamatsu wrote:
> But I want to install version 4.69 to squeeze with #593172 ,#592982 and #568301.
> Beacause this version (in 4.67) was fixed API.
- 593172: init script tries to start service when removed but not purged
- 592982, 568301: stale file in modprobe.d has the wrong filename
- 589727: fix the return value of read_device_alias
Could you elaborate on the API change?
The beginning of a review follows. Please forgive my ignorance.
> ChangeLog | 22 +
> Makefile.in | 189 ++++++------
> configure | 76 +++--
[...]
> debian/libbluetooth3.symbols | 336 +++++++++++-----------
API change.
[...]
> doc/attribute-api.txt | 97 ++++++
> doc/network-api.txt | 38 +-
[...]
> 73 files changed, 3478 insertions(+), 1614 deletions(-)
Still pretty large, and the bulk is real code changes (fixes, hopefully).
> +++ bluez-4.69/ChangeLog 2010-07-13 16:08:59.000000000 +0900
> @@ -1,3 +1,25 @@
> +ver 4.69:
> + Fix issue with calling g_option_context_free() twice.
Sounds useful.
> + Fix inconsistencies with initial LE commands and events.
> + Add support for telephony ClearLastNumber method.
> + Add support for network server interface.
> +
> +ver 4.68:
> + Fix initialization of adapters in RAW mode.
> + Fix signal strength for HFP in Maemo's telephony support.
> + Add support for following the radio state via Maemo's MCE.
> + Add initial set of LE commands and events definitions.
> + Add mode option for L2CAP sockets to the BtIO API.
What are these about?
> +
> +ver 4.67:
> + Fix issue with authentication reply when bonding already completed.
> + Fix issue with not canceling authentication when bonding fails.
> + Fix issue with changed combination keys and temporary storage.
> + Fix issue with sdp_get_supp_feat library function.
> + Fix issue with missing unblock on device removal.
> + Fix issue with not waiting for mode change completion.
These sound like useful, unrisky changes.
> + Add ARMv6 optimized version of analysis filter for SBC encoder.
> +
IIRC Debian can be run on armv4. Have you checked that this will not
break bluez on such machines?
> --- bluez-4.66/Makefile.am 2010-05-23 21:47:19.000000000 +0900
> +++ bluez-4.69/Makefile.am 2010-07-13 16:08:59.000000000 +0900
> @@ -53,7 +53,7 @@
>
> lib_libbluetooth_la_SOURCES = $(lib_headers) \
> lib/bluetooth.c lib/hci.c lib/sdp.c
> -lib_libbluetooth_la_LDFLAGS = -version-info 11:0:8
> +lib_libbluetooth_la_LDFLAGS = -version-info 12:0:9
ABI-compatible, just some new ABI (phew).
[...]
> --- bluez-4.66/audio/a2dp.c 2010-06-12 16:45:14.000000000 +0900
> +++ bluez-4.69/audio/a2dp.c 2010-07-03 04:40:38.000000000 +0900
> @@ -112,14 +112,14 @@
> {
> setup->ref++;
>
> - DBG("setup_ref(%p): ref=%d", setup, setup->ref);
> + DBG("%p: ref=%d", setup, setup->ref);
[...]
Some no-op noise.
> --- bluez-4.66/audio/avdtp.c 2010-06-12 16:45:14.000000000 +0900
> +++ bluez-4.69/audio/avdtp.c 2010-07-03 04:40:38.000000000 +0900
> @@ -807,7 +803,8 @@
> - avdtp_close(session, stream, FALSE);
> + if (avdtp_close(session, stream, FALSE) < 0)
> + error("stream_timeout: closing AVDTP stream failed");
Yay. :)
> --- bluez-4.66/audio/gstbluetooth.c 2010-01-10 05:52:17.000000000 +0900
> +++ bluez-4.69/audio/gstbluetooth.c 2010-07-03 04:40:38.000000000 +0900
> @@ -50,21 +50,24 @@
Looks sane and useful.
> --- bluez-4.66/audio/manager.c 2010-06-12 16:45:14.000000000 +0900
> +++ bluez-4.69/audio/manager.c 2010-07-03 04:40:38.000000000 +0900
> @@ -351,12 +350,18 @@
[...]
> + if (!network) {
> + sdp_record_free(record);
> + return NULL;
> + }
Likewise.
> --- bluez-4.66/audio/pcm_bluetooth.c 2010-01-10 05:52:17.000000000 +0900
> +++ bluez-4.69/audio/pcm_bluetooth.c 2010-07-03 04:40:38.000000000 +0900
> @@ -1007,7 +1007,7 @@
> snd_pcm_sframes_t ret = 0;
> unsigned int bytes_left;
> int frame_size, encoded;
> - size_t written;
> + ssize_t written;
> uint8_t *buff;
For the future: it can be useful to use -p/--show-c-function to make
this kind of hunk more self-explanatory. Will file a bug for debdiff
if I remember.
> --- bluez-4.66/audio/telephony-maemo6.c 2010-05-23 21:47:19.000000000 +0900
> +++ bluez-4.69/audio/telephony-maemo6.c 2010-07-13 16:08:59.000000000 +0900
> @@ -134,11 +134,14 @@
> static struct {
> char *operator_name;
> uint8_t status;
> - int32_t signals_bar;
> + int32_t signal_bars;
Recalibrating. The dbus message has been renamed from
SignalStrengthChanged to SignalBarsChanged to go along with that;
are any Debian packages affected?
[...]
> @@ -1896,8 +1909,8 @@
> "OperatorNameChanged"))
> handle_operator_name_changed(msg);
> else if (dbus_message_is_signal(msg, CSD_CSNET_SIGNAL,
> - "SignalStrengthChanged"))
> - handle_signal_strength_changed(msg);
> + "SignalBarsChanged"))
> + handle_signal_bars_changed(msg);
> else if (dbus_message_is_signal(msg, "org.freedesktop.Hal.Device",
> "PropertyModified"))
> handle_hal_property_modified(msg);
[...]
> @@ -1978,6 +1991,12 @@
>
> void telephony_exit(void)
> {
> + g_free(net.operator_name);
> + net.operator_name = NULL;
> +
> + g_free(last_dialed_number);
> + last_dialed_number = NULL;
Plugging memory leaks.
[...]
> --- bluez-4.66/configure.ac 2010-06-12 16:45:14.000000000 +0900
> +++ bluez-4.69/configure.ac 2010-07-13 16:08:59.000000000 +0900
> @@ -1,5 +1,5 @@
> AC_PREREQ(2.60)
> -AC_INIT(bluez, 4.66)
> +AC_INIT(bluez, 4.69)
Fair enough.
> --- bluez-4.66/debian/bluez.bluetooth.init 2010-10-04 09:09:31.000000000 +0900
> +++ bluez-4.69/debian/bluez.bluetooth.init 2010-10-04 09:09:32.000000000 +0900
> @@ -39,6 +39,8 @@
>
> SSD_OPTIONS="--oknodo --quiet --exec $DAEMON"
>
> +test -f /usr/sbin/bluetoothd || exit 0
> +
> test -f /etc/default/bluetooth && . /etc/default/bluetooth
> test -f /etc/default/rcS && . /etc/default/rcS
Fixes bug#593172.
> --- bluez-4.66/debian/bluez.preinst 2010-10-04 09:09:31.000000000 +0900
> +++ bluez-4.69/debian/bluez.preinst 2010-10-04 09:09:32.000000000 +0900
> @@ -48,7 +48,7 @@
> # now that modprobe whines remove this old conffile, will be
> # http://bugs.debian.org/523050
> base="/etc/modprobe.d/bluez"
> - rm_conffile "$base"
> + rm_conffile bluez "$base"
Typo fix. Fixes bug#592982, 568301.
[...]
> --- bluez-4.66/debian/libbluetooth3.symbols 2010-10-04 09:09:31.000000000 +0900
> +++ bluez-4.69/debian/libbluetooth3.symbols 2010-10-04 09:09:32.000000000 +0900
> @@ -31,169 +31,173 @@
> hci_for_each_dev@Base 4.43
> hci_get_route@Base 4.43
> hci_inquiry@Base 4.43
> - hci_lmtostr@Base 4.43
> + hci_lmtostr@Base 4.66
> - hci_lptostr@Base 4.43
> + hci_lptostr@Base 4.66
[...]
Fixing typos? Or what prompted this? The changely for 4.67 just says
"Update libbluetooth3.symbols".
Unfortunately this makes it hard to find what symbols are new amid all the
noise.
> --- bluez-4.66/doc/attribute-api.txt 1970-01-01 09:00:00.000000000 +0900
> +++ bluez-4.69/doc/attribute-api.txt 2010-07-12 13:22:20.000000000 +0900
> @@ -0,0 +1,97 @@
> +BlueZ D-Bus Attribute API description
Yay. :)
[...]
> --- bluez-4.66/doc/network-api.txt 2010-02-13 04:26:48.000000000 +0900
> +++ bluez-4.69/doc/network-api.txt 2010-07-13 16:08:59.000000000 +0900
> @@ -60,35 +60,29 @@
> Indicates the connection role when available.
>
>
> -Network Hub/Peer/Router hierarchy
> -=================
> +Network server hierarchy
> +========================
>
> Service org.bluez
> -Interface org.bluez.network.{Hub, Peer, Router}
> +Interface org.bluez.NetworkServer
Is this just bringing the documentation up to date or was there an API
change?
> --- bluez-4.66/lib/bluetooth.c 2010-05-23 21:47:19.000000000 +0900
> +++ bluez-4.69/lib/bluetooth.c 2010-07-12 13:22:20.000000000 +0900
> @@ -474,6 +474,12 @@
> return "Belkin International, Inc.";
> case 93:
> return "Realtek Semiconductor Corporation";
> + case 94:
> + return "Stonestreet One, LLC";
> + case 95:
> + return "Wicentric, Inc.";
> + case 96:
> + return "RivieraWaves S.A.S";
New company IDs (just cosmetic).
> --- bluez-4.66/lib/hci.c 2010-05-23 21:47:19.000000000 +0900
> +++ bluez-4.69/lib/hci.c 2010-07-13 16:08:59.000000000 +0900
> @@ -1093,6 +1093,7 @@
> hci_filter_set_ptype(HCI_EVENT_PKT, &nf);
> hci_filter_set_event(EVT_CMD_STATUS, &nf);
> hci_filter_set_event(EVT_CMD_COMPLETE, &nf);
> + hci_filter_set_event(EVT_LE_META_EVENT, &nf);
> hci_filter_set_event(r->event, &nf);
> hci_filter_set_opcode(opcode, &nf);
> if (setsockopt(dd, SOL_HCI, HCI_FILTER, &nf, sizeof(nf)) < 0)
[...]
Out of my depth. Presumably this exposes more events from already
supported bluetooth devices?
My editor tells me I'm only 5% of the way into the diff, so I'm
stopping here. Have you looked over the changes and can you
summarize their impact?
The motivating examples (bug#593172, bug#592982, return value from
read_device_alias) amount to about 10 lines and this is many more
than that.
Thanks,
Jonathan
Reply to: