| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* 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 <Martin.Jansa@gmail.com>
|
| |
|
|
|
|
|
|
|
| |
because of python-pygobject is broken"
This reverts commit b0fae32dfc447ef9864e077d05c51bbbf763565b.
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
|
| |
|
|
|
|
| |
python-pygobject is broken
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
|
| |
|
|
|
|
|
| |
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 <alexander.kanavin@linux.intel.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <ashcharles@gmail.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
|
| |
|
|
|
|
| |
gst-plugin-bluetooth, gnome-bluetooth: blacklist bluez4 only recipes when bluez5 is in DISTRO_FEATURES
foo
|
|
|
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 <cristian.iorga@intel.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
|
