On 24/01/14 18:30, Dan Williams wrote:
On Fri, 2014-01-24 at 12:21 +0100, David Sommerseth wrote:
> On 23/01/14 21:19, Dan Williams wrote:
>> On Thu, 2014-01-23 at 14:17 -0600, Dan Williams wrote:
>>> On Thu, 2014-01-23 at 20:04 +0100, David Sommerseth wrote:
>>>> On 23/01/14 19:58, Frank Murphy wrote:
>>>>> On Thu, 23 Jan 2014 19:53:19 +0100
> [...snip...]
>>>> Might even be a worse conflict for other users, depending on installed
>>>> packages. I believe there's no way around re-compiling
NetworkManager,
>>>> pulseaudio and other GNOME and KDE packages depending on bluez.
>>>
>>> NM only uses bluez via the D-Bus interface, so if you force install
>>> bluez4, NM will still work and should even handle the change at runtime.
>>> And then you'll get DUN back too :)
>>
>> Clarification: I actually don't mean runtime. NM must be restarted to
>> notice the change from bluez4 <-> bluez5, but it does not need to be
>> recompiled.
>
> The DBus interface with bluez5 have changed too.
>
> <
http://www.bluez.org/bluez-5-api-introduction-and-porting-guide/>
>
> Does NM support both bluez NM APIs?
Correct. It determines which one to use when it starts up, based on what
version of bluez is running at that time.
Perfect!
However, because of a significant change in how DUN works with
Bluez5,
NetworkManager does not (yet!) support DUN when Bluez5 is running. We
are working on that.
Thanks a lot! It makes more sense after having poked at this today.
I've been doing some local mockbuilds today, and noticed I could enable
bluez4 in the NM spec file (it was set to --enable-bluez4=no, afaics),
and I seems to produce some nm-bluez4 files. Now I just need to get the
proper version built, I built the fedpkg NM master by mistake.
--
kind regards,
David Sommerseth