Bug 481801 - solid bluetooth patches
solid bluetooth patches
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: kdebase-workspace (Show other bugs)
10
All Linux
low Severity medium
: ---
: ---
Assigned To: Rex Dieter
Fedora Extras Quality Assurance
: Patch
Depends On:
Blocks: kde42 481802
  Show dependency treegraph
 
Reported: 2009-01-27 12:32 EST by Rex Dieter
Modified: 2009-02-09 13:31 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-02-09 13:31:23 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
updated solid/bluetooth support (41.85 KB, patch)
2009-01-27 12:32 EST, Rex Dieter
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
KDE Software Compilation 172267 None None None Never

  None (edit)
Description Rex Dieter 2009-01-27 12:32:21 EST
Created attachment 330124 [details]
updated solid/bluetooth support

Per the kde-sig meeting today, these patches are presumably required for newer kdebluetooth builds.
Comment 1 Ngo Than 2009-01-28 11:07:52 EST
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.
Comment 2 Rex Dieter 2009-01-28 12:14:48 EST
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
Comment 3 Rex Dieter 2009-01-28 13:07:32 EST
Than, confirmed, kdebluetooth-0.3 build fails against stock 4.2.0,
http://koji.fedoraproject.org/koji/taskinfo?taskID=1089289

Now what?
Comment 4 Kevin Kofler 2009-01-28 13:15:06 EST
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.
Comment 5 Kevin Kofler 2009-01-28 13:17:09 EST
(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).)
Comment 6 Ngo Than 2009-01-29 05:42:24 EST
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).
Comment 7 Rex Dieter 2009-01-29 08:41:35 EST
OK, removing from kde42 blocker.
Comment 8 Kevin Kofler 2009-01-29 11:23:25 EST
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.
Comment 9 Kevin Kofler 2009-01-29 11:29:24 EST
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.
Comment 10 Kevin Kofler 2009-01-29 11:52:34 EST
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.
Comment 11 Kevin Kofler 2009-01-29 12:14:17 EST
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!
Comment 12 Kevin Kofler 2009-01-29 12:32:21 EST
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.
Comment 13 Rex Dieter 2009-01-29 13:02:54 EST
eww, let's give it a shot.
Comment 14 Rex Dieter 2009-01-29 15:40:33 EST
Alrighty F-10+ integrated in kdebase-workspace-4.2.0-3
Comment 15 Kevin Kofler 2009-01-29 17:46:59 EST
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.
Comment 16 Ngo Than 2009-01-30 10:38:29 EST
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).
Comment 17 Rex Dieter 2009-01-30 10:58:38 EST
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.
Comment 18 Kevin Kofler 2009-01-30 11:03:49 EST
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". :-/
Comment 19 Kevin Kofler 2009-02-09 13:31:23 EST
Fixed in the latest 4.2 testing update, 4.1 not affected, closing.

Note You need to log in before you can comment on or make changes to this bug.