Bug 481801

hm, why does the new kdebluetooth not build against 4.2.0? It's not a good idea to add this patch in 4.2.0.

kdebluetooth should be fixed to build against 4.2.0.

I don't know the answer(s), I wass just reporting my perception of the conversations @ http://bugs.kde.org/show_bug.cgi?id=172267#c20

Than, confirmed, kdebluetooth-0.3 build fails against stock 4.2.0,
http://koji.fedoraproject.org/koji/taskinfo?taskID=1089289

Now what?

We need versions of kdebluetooth and solid/bluetooth which:
* work with each other and
* work with the version of BlueZ we're shipping.

If upgrading solid/bluetooth is needed, then I don't see why we shouldn't do it. I don't think anything other than kdebluetooth actually uses it.

(And the version in upstream 4.2.0 *already* breaks binary compatibility, so that's not an argument either. See https://bugs.kde.org/show_bug.cgi?id=179224 (which got ignored entirely).)

We make the api change if we add the patch in our kde-4.2.0. It's bad if we do that from our side. I'm pretty sure the kde developers will complain here again.

The correct way is we have to contact the solid/bluetooth maintainer and ask him to backport this into 4.2.0 branch or ask the kdebluetooth maintainer to fix kdebluetooth to build against 4.2.0.

If it's unrealisable we should probably revert it to the old kdebluetooth (kde3).

OK, removing from kde42 blocker.

I disagree strongly with Than here.

> We make the api change if we add the patch in our kde-4.2.0. It's bad if we do
> that from our side. I'm pretty sure the kde developers will complain here
> again.

The Solid Bluetooth API is only used by kdebluetooth at this time. I don't see how API changes can hurt here. Even upstream changed the API from 4.1 to 4.2, which is why kdebluetooth now fails with unresolved symbols!

And OpenSUSE ships that patch already.

> The correct way is we have to contact the solid/bluetooth maintainer and ask
> him to backport this into 4.2.0 branch

Unfortunately, if there are really API changes involved, I doubt upstream will be willing to backport those to 4.2.x. And in addition, we need them for the 4.2.0 update, not 4.2.1 or some later time.

> or ask the kdebluetooth maintainer to fix kdebluetooth to build against 4.2.0.

I don't think that's feasible, as the changes are needed to support BlueZ 4 properly (which is the version currently in F10 and Rawhide). The current kdebluetooth is reported to be sorta working, but flaky on F10, I'm sure this is why. (I think they're using some BlueZ 3 compatibility API.)

> If it's unrealisable we should probably revert it to the old kdebluetooth
> (kde3).

That version also does not support BlueZ 4, and it was also working poorly in KDE 4, which is why it got upgraded to the KDE 4 version even in released distributions in the first place. So this is not an option either.

Shipping KDE 4.2.0 updates with broken Bluetooth is not an option, so readding to the KDE 4.2 blocker. We do need those patches.

Kubuntu dropped support for Bluetooth entirely in Intrepid because of the BlueZ 4 issues, I think that's not a good idea and it will also mean that if there are any apps using the Solid Bluetooth API other than kdebluetooth (which I doubt), they will not work. I don't see how shipping a changed API is worse than shipping none at all, when the main/only user of that API (kdebluetooth) needs the changed version and when it is needed to integrate properly into the system (BlueZ 4). OpenSUSE is shipping the patched API to make Bluetooth just work, we should follow suit.

And I'll add that on F9, which has BlueZ 3 and thus a fully working kdebluetooth, pushing KDE 4.2.0 out without a working kdebluetooth (and the current one is not working with 4.2, it has unresolved symbols) will be a bad regression.

I just checked: it looks like kdebluetooth 0.3 REQUIRES BlueZ 4. So in F9 we can't ship that at the moment. In F9, we'll have to rebuild kdebluetooth 0.2 instead, and if it doesn't build against Solid Bluetooth from 4.2, revert Solid Bluetooth to the version from 4.1.

I just confirmed: KDE 4.2 ships a completely useless Solid Bluetooth API.
http://websvn.kde.org/branches/KDE/4.2/kdebase/workspace/solid/bluez/bluez-bluetoothmanager.cpp?view=log
It got ported to BlueZ 4, but the port is not complete. So it won't work with any version of BlueZ and kdebluetooth.
* On F9, we have BlueZ 3, so we need kdebluetooth 0.2 and an older Solid Bluetooth code.
* On F10, we have BlueZ 4, so we need kdebluetooth 0.3 and a newer Solid Bluetooth code.
Fun!

For F9 / kdebluetooth 0.2, we have to revert the following files and directories in kdebase-workspace to the versions from KDE 4.1:
libs/solid/control/backends/CMakeLists.txt
libs/solid/control/bluetooth*
libs/solid/control/ifaces/bluetooth*
libs/solid/bluez/

I'll prepare a patch.

For F10 and Rawhide, we need the patches from openSUSE (which come from the upstream kdebluetooth and Solid-Bluetooth maintainer, Tom Patzig, who works at openSUSE!) and kdebluetooth 0.3.

eww, let's give it a shot.

Alrighty F-10+ integrated in kdebase-workspace-4.2.0-3

For F9, kdebase-workspace-4.2.0-4.fc9.1 built with a reverted Solid Bluetooth stack which should work with the old kdebluetooth4 0.2 and BlueZ 3.

i'm not happy to have this patch in our kde packages, i know that kde upstream has maden the api change, it's bad what they did in the stable release.

imo we should revert kdebluetooth to old kdebluetooth (kde3).

Than, (re)read Kevin's comments 9-11.

The old bluetooth is doable with bluez3/F-9, and that's what has been implemented.  For F10+, that's not an option.

What has been implemented for F9 is actually that I reverted the Solid Bluetooth stuff to the code from 4.1.4 which works with kdebluetooth4 0.2.

And yes, for F10+ I think kdebluetooth4 0.3 and matching Solid backports is the only way forward.

I think the real problem is that this code is in kdebase-workspace when it really belongs to kdebluetooth, nothing else uses it and they're tightly coupled. This looks to me like the only reason this code is in KDE is so the kdebluetooth project can say "we're using Solid". :-/

Fixed in the latest 4.2 testing update, 4.1 not affected, closing.