Review request: QBluez
David Rosca
nowrep at gmail.com
Tue Feb 17 22:10:16 GMT 2015
> Well, then the test should try to detect it and QEXPECT_FAIL, havign tests
> fail means something is bad, and as you say it's not bad, just expected.
I meant it's expected to fail in the case that something goes wrong when
initializing Manager. And that is, for example, the case with running Bluez 4
instead of Bluez 5.
The problem is that there are some tests that are running on the real Bluez
daemon and those tests obviously requires Bluez 5. They won't fail when
there is no org.bluez on system bus, but they will actually fail when there
is org.bluez but provided by Bluez 4.
I will modify those tests to be skipped if Bluez 4 is detected.
David
On Tue, Feb 17, 2015 at 11:00 PM, Albert Astals Cid <aacid at kde.org> wrote:
> El Dimarts, 17 de febrer de 2015, a les 22:39:16, David Rosca va escriure:
>> > That would work i guess, note it's not only about the project name, but
>> > also about the class names.
>>
>> Sure.
>>
>> > But i get two others to fail
>> > Any idea?
>>
>> Hmm, I would say that it is actually expected to fail if there is an
>> error when calling
>> GetManagedObjects on org.freedesktop.DBus.ObjectManager.
>> By any chance, are you running Bluez 4?
>
> I am.
>
>> It doesn't have the DBus
>> ObjectManager, so that call should fail like that.
>
> Well, then the test should try to detect it and QEXPECT_FAIL, havign tests
> fail means something is bad, and as you say it's not bad, just expected.
>
> Cheers,
> Albert
>
>>
>> David
>>
>> On Tue, Feb 17, 2015 at 10:23 PM, Albert Astals Cid <aacid at kde.org> wrote:
>> > El Dimarts, 17 de febrer de 2015, a les 10:36:59, David Rosca va escriure:
>> >> > Using Q* is usually frowned upon since the Qt people have made it quick
>> >> > clear that they reserve the right to use Q* names themselves, i'd look
>> >> > for a new name.
>> >>
>> >> I see. What about renaming it to BluezQt?
>> >
>> > That would work i guess, note it's not only about the project name, but
>> > also about the class names.
>> >
>> >> > Also tried to run the tests and qbluez-managertest seems to get stuck
>> >> > forever. Does it take much to run? Does it need that i actually have
>> >> > bluetooth hardware?
>> >>
>> >> Tests are running with both real org.bluez (system bus) and fake
>> >> org.qbluez.bluez (session bus). You don't need to have any bluetooth
>> >> hardware, nor Bluez installed at all to run the tests.
>> >>
>> >> The reason why it hangs is probably that fakebluez cannot, for some
>> >> reason, start.
>> >> I have pushed a change that fixes the hang, and also show some info why
>> >> it
>> >> cannot start.
>> >> Can you please send me the output of qbluez-managertest?
>> >
>> > Now it doesnt' fail :D
>> >
>> >
>> >
>> > But i get two others to fail
>> > 4: Test command: /home/kdeunstable/qbluez/build/autotests/adaptertest
>> > 4: Test timeout computed to be: 9.99988e+06
>> > 4: ********* Start testing of AdapterTest *********
>> > 4: Config: Using QtTest library 5.4.0, Qt 5.4.0 (x86_64-little_endian-lp64
>> > shared (dynamic) release build; by GCC 4.9.2)
>> > 4: QWARN : AdapterTest::initTestCase() QBluez: GetManagerJob Error:
>> > "Rejected send message, 2 matched rules; type="method_call",
>> > sender=":1.171" (uid=1003 pid=11623
>> > comm="/home/kdeunstable/qbluez/build/autotests/adapterte")
>> > interface="org.freedesktop.DBus.ObjectManager" member="GetManagedObjects"
>> > error name="(unset)" requested_reply="0" destination="org.bluez" (uid=0
>> > pid=514 comm="/usr/sbin/bluetoothd ")"
>> > 4: FAIL! : AdapterTest::initTestCase() '!initJob->error()' returned
>> > FALSE. () 4: Loc:
>> > [/home/kdeunstable/qbluez/autotests/adaptertest.cpp(71)] 4: PASS :
>> > AdapterTest::cleanupTestCase()
>> > 4: Totals: 1 passed, 1 failed, 0 skipped, 0 blacklisted
>> > 4: ********* Finished testing of AdapterTest *********
>> > 4/6 Test #4: qbluez-adaptertest ...............***Failed 0.01 sec
>> > test 5
>> >
>> > Start 5: qbluez-devicetest
>> >
>> > 5: Test command: /home/kdeunstable/qbluez/build/autotests/devicetest
>> > 5: Test timeout computed to be: 9.99988e+06
>> > 5: ********* Start testing of DeviceTest *********
>> > 5: Config: Using QtTest library 5.4.0, Qt 5.4.0 (x86_64-little_endian-lp64
>> > shared (dynamic) release build; by GCC 4.9.2)
>> > 5: QWARN : DeviceTest::initTestCase() QBluez: GetManagerJob Error:
>> > "Rejected send message, 2 matched rules; type="method_call",
>> > sender=":1.172" (uid=1003 pid=11624
>> > comm="/home/kdeunstable/qbluez/build/autotests/devicetes")
>> > interface="org.freedesktop.DBus.ObjectManager" member="GetManagedObjects"
>> > error name="(unset)" requested_reply="0" destination="org.bluez" (uid=0
>> > pid=514 comm="/usr/sbin/bluetoothd ")"
>> > 5: FAIL! : DeviceTest::initTestCase() '!initJob->error()' returned FALSE.
>> > () 5: Loc: [/home/kdeunstable/qbluez/autotests/devicetest.cpp(91)] 5:
>> > PASS : DeviceTest::cleanupTestCase()
>> > 5: Totals: 1 passed, 1 failed, 0 skipped, 0 blacklisted
>> > 5: ********* Finished testing of DeviceTest *********
>> > 5/6 Test #5: qbluez-devicetest ................***Failed 0.01 sec
>> > test 6
>> >
>> > Start 6: qbluez-jobstest
>> >
>> > Any idea?
>> >
>> > Cheers,
>> >
>> > Albert
>> >>
>> >> Thanks,
>> >> David
>> >>
>> >> On Mon, Feb 16, 2015 at 11:51 PM, Albert Astals Cid <aacid at kde.org>
> wrote:
>> >> > El Dilluns, 16 de febrer de 2015, a les 10:40:44, David Rosca va
> escriure:
>> >> >> Hi all,
>> >> >> I'd like to ask for a review of the QBluez library [1].
>> >> >
>> >> > Using Q* is usually frowned upon since the Qt people have made it quick
>> >> > clear that they reserve the right to use Q* names themselves, i'd look
>> >> > for a new name.
>> >> >
>> >> > Also tried to run the tests and qbluez-managertest seems to get stuck
>> >> > forever. Does it take much to run? Does it need that i actually have
>> >> > bluetooth hardware?
>> >> >
>> >> > Cheers,
>> >> >
>> >> > Albert
>> >> >>
>> >> >> QBluez is a Qt 5 wrapper for Bluez 5 DBus API.
>> >> >> I have started working on it as a GSoC 2014 project.
>> >> >> It is intended to be a libbluedevil replacement, main
>> >> >> difference being that every DBus call is made asynchronous.
>> >> >> It also exposes more Bluez API than libbluedevil, including
>> >> >> Obex API.
>> >> >>
>> >> >> This library will be used in Bluedevil frameworks branch.
>> >> >> I have also written a new Bluetooth plasmoid [2] that uses
>> >> >> a QBluez QML plugin.
>> >> >>
>> >> >> Bellow is a list of some additional QBluez features compared
>> >> >>
>> >> >> to libbluedevil:
>> >> >> * it is a tier 1 framework
>> >> >>
>> >> >> * asynchronous API using jobs/pending calls with possibility
>> >> >>
>> >> >> to run synchronously (for tests/cli apps)
>> >> >>
>> >> >> * extended API - this currently includes API for Obex File
>> >> >>
>> >> >> Transfer, Obex Object Push and Profile API for implementing
>> >> >> Bluetooth profiles
>> >> >>
>> >> >> * build-time optional QML plugin - currently exposing Manager,
>> >> >>
>> >> >> Adapter, Device, DevicesModel and PendingCall
>> >> >>
>> >> >> * possibility to be notified when method call finishes
>> >> >>
>> >> >> and to be notified about possible errors
>> >> >>
>> >> >> Currently, there is a qbluez branch in Bluedevil [3]. It will
>> >> >> be merged to frameworks branch once QBluez is reviewed.
>> >> >>
>> >> >> You can find generated documentation here [4].
>> >> >>
>> >> >> Thanks,
>> >> >> David Rosca
>> >> >>
>> >> >> [1] http://quickgit.kde.org/?p=scratch%2Fdrosca%2Fqbluez.git
>> >> >> [2] https://github.com/nowrep/qbluez-plasmoid
>> >> >> [3]
>> >> >> https://projects.kde.org/projects/kde/workspace/bluedevil/repository/s
>> >> >> how
>> >> >> ?r
>> >> >> ev=qbluez [4] http://david.rosca.cz/qbluez-apidoc/html/
>> >> >> _______________________________________________
>> >> >> Kde-frameworks-devel mailing list
>> >> >> Kde-frameworks-devel at kde.org
>> >> >> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
>> >>
>> >> _______________________________________________
>> >> Kde-frameworks-devel mailing list
>> >> Kde-frameworks-devel at kde.org
>> >> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
>>
>> _______________________________________________
>> Kde-frameworks-devel mailing list
>> Kde-frameworks-devel at kde.org
>> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
>
More information about the kde-core-devel
mailing list