linux/meta-openembedded.git/meta-oe/recipes-connectivity/bluez/bluez4_4.101.bb, branch thud-next

bluez4: remove bluez4-only recipes

2017-08-13T11:21:00+00:00

* remove recipes which support only bluez4 and are blacklisted when bluez5 is selected in DISTRO_FEATURES, if someone is still using bluez4, then it can be restored in separate meta-bluez4 and maintained by people using it. * there are few recipes which support both bluez5 or bluez4 based on selected DISTRO_FEATURES, these can stay in meta-oe repository, but now people without bluez5 in DISTRO_FEATURES will need to add meta-bluez4 layer to satisfy bluez4 dependency meta-gnome/recipes-connectivity/obex/obexd_0.48.bb:DEPENDS += "${@bb.utils.contains('DISTRO_FEATURES','bluez5','bluez5','bluez4',d)}" meta-gnome/recipes-gnome/gnome-bluetooth/gnome-bluetooth_3.18.2.bb: ${@bb.utils.contains('DISTRO_FEATURES','bluez5','bluez5','bluez4',d)} \ meta-oe/recipes-connectivity/obex/obex-data-server_0.4.6.bb:DEPENDS += "${@bb.utils.contains('DISTRO_FEATURES','bluez5','bluez5','bluez4',d)}" meta-oe/recipes-connectivity/obex/openobex_1.7.2.bb:DEPENDS_append_class-target = " ${@bb.utils.contains('DISTRO_FEATURES','bluez5','bluez5','bluez4',d)}" meta-oe/recipes-connectivity/packagegroups/packagegroup-tools-bluetooth.bb:RDEPENDS_bluez4 = " \ meta-oe/recipes-connectivity/packagegroups/packagegroup-tools-bluetooth.bb:# Install bluez4 tools or bluez5 tools depending on what is specified in the distro. Signed-off-by: Martin Jansa

Revert "python-pygobject, python-cloudeebus, python-dbusmock: Blacklist because of python-pygobject is broken"

2016-06-23T13:21:26+00:00

This reverts commit b0fae32dfc447ef9864e077d05c51bbbf763565b. Signed-off-by: Hongxu Jia Signed-off-by: Martin Jansa

python-pygobject, python-cloudeebus, python-dbusmock: Blacklist because of python-pygobject is broken

2016-06-13T17:06:46+00:00

Signed-off-by: Martin Jansa

bluez4: use real introspection instead of legacy pygobject

2016-03-14T11:15:29+00:00

Now that the real introspection is available, and legacy pygobject is not, the patch to use the latter should be removed. Signed-off-by: Alexander Kanavin

bluez4: Allow systemd to activate bluetooth

2015-08-18T09:38:04+00:00

The bluetooth.service runs bluetoothd to manage bluetooth devices, if present, in the system. By design, it should be running in either of two cases: 1. A userspace utility (e.g. networkmanager) has made a dbus request for bluetooth services provided by org.bluez. Even without this patch, the bluetooth.service gets run via dbus activation under the systmed aliased name 'dbus-org-bluez.service'. Perfect! 2. A bluetooth device is added to the system. When a bluetooth device is added, udev triggers the special systemd target, bluetooth.target intended to pull in any services needed for bluetooth linked under bluetooth.target.wants. Enable bluetooth.service so it gets linked under bluetooth.target.wants and bluetoothd gets started when a user adds a bluetooth device to the system. To be clear, this isn't forcing bluetooth to be running all the time--- only when either of #1 or #2 are true. Signed-off-by: Ash Charles Signed-off-by: Martin Jansa

obex, navit, libsyncml, foxtrotgps, gypsy, bluez-hcidump, bluez4, gst-plugin-bluetooth, gnome-bluetooth: blacklist bluez4 only recipes when bluez5 is in DISTRO_FEATURES

2015-05-11T08:27:28+00:00

foo

bluez collection: add (moved from oe-core)

2015-05-11T08:25:53+00:00

BlueZ 4.x Bluetooth stack has been removed from oe-core. However, it is still supported, so add it to recipes-connectivity in meta-oe. meta-systemd layer bluez4 bbappend has been integrated into bluez4 recipe. In order to use it in oe-core/poky/YP, 'bluez5' backfill distro feature needs to be disabled via: DISTRO_FEATURES_BACKFILL_CONSIDERED = "bluez5" . 'bluetooth' distro feature needs to be present also. Signed-off-by: Cristian Iorga Signed-off-by: Martin Jansa