Review request: QBluez

[David Rosca]

I have made yet another changes and I think it is ready
to be used in Bluedevil.
However, I'm not really sure how should I proceed now.

Can I move it to playground repo (+ add it to reviewboard and set
a jenkins build)?
Would it be ok for a Bluedevil (in workspace) to depend on a library
in playground?

After that, I'd like to request a review to make BluezQt an official framework.
Or should I get it reviewed first and use it in Bluedevil only after reviewed?

Thanks,
David

On Sat, Feb 21, 2015 at 1:36 AM, Albert Astals Cid <aacid at kde.org> wrote:
> El Dissabte, 21 de febrer de 2015, a les 00:24:16, David Rosca va escriure:
>> > Still failing here
>>
>> Oops, sorry. It's because the problem is not that you are running
>> Bluez 4, but because the method call is rejected (auth issue?).
>>
>> Anyway, I modified the tests again so that it now checks whether
>> the Bluez 5 is running and is functional (it checks if the call to
>> GetManagedObjects succeeds). It should catch your error
>> and correctly skip the tests now.
>
> Yep that's all fine now :)
>
> Cheers,
>   Albert
>
>>
>> David
>>
>> On Fri, Feb 20, 2015 at 9:57 PM, Albert Astals Cid <aacid at kde.org> wrote:
>> > El Dimecres, 18 de febrer de 2015, a les 11:50:01, David Rosca va
> escriure:
>> >> > If it's an expected situation, handle the situation.
>> >>
>> >> I have modified the tests (only the ones who would fail) so they will
>> >> be skipped if Bluez 4 is detected.
>> >
>> > Still failing here
>> >
>> > 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() BluezQt: GetManagerJob Error: "Rejected send
>> > message, 2 matched rules; type="method_call", sender=":1.145" (uid=1003
>> > pid=10596 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=556 comm="/usr/sbin/bluetoothd ")" 4: FAIL!  :
>> > AdapterTest::initTestCase() '!initJob->error()' returned FALSE. () 4:
>> > Loc: [/home/kdeunstable/qbluez/autotests/adaptertest.cpp(76)] 4: PASS   :
>> > AdapterTest::cleanupTestCase()
>> > 4: Totals: 1 passed, 1 failed, 0 skipped, 0 blacklisted
>> > 4: ********* Finished testing of AdapterTest *********
>> > 4/6 Test #4: bluezqt-adaptertest ..............***Failed    0.01 sec
>> > test 5
>> >
>> >     Start 5: bluezqt-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() BluezQt: GetManagerJob Error: "Rejected send
>> > message, 2 matched rules; type="method_call", sender=":1.146" (uid=1003
>> > pid=10597 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=556 comm="/usr/sbin/bluetoothd ")" 5: FAIL!  :
>> > DeviceTest::initTestCase() '!initJob->error()' returned FALSE. () 5:
>> > Loc: [/home/kdeunstable/qbluez/autotests/devicetest.cpp(96)] 5: PASS   :
>> > DeviceTest::cleanupTestCase()
>> > 5: Totals: 1 passed, 1 failed, 0 skipped, 0 blacklisted
>> > 5: ********* Finished testing of DeviceTest *********
>> > 5/6 Test #5: bluezqt-devicetest ...............***Failed    0.01 sec
>> >
>> >> I have also renamed the library to BluezQt. Here is an updated
>> >> documentation: http://david.rosca.cz/bluezqt-apidocs/html/
>> >>
>> >> David
>> >>
>> >> On Wed, Feb 18, 2015 at 2:19 AM, Thiago Macieira <thiago at kde.org> wrote:
>> >> > On Tuesday 17 February 2015 23:00:15 Albert Astals Cid wrote:
>> >> >> > 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.
>> >> >
>> >> > QEXPECT_FAIL is when you know it's wrong but either can't solve it or
>> >> > can't do it now.
>> >> >
>> >> > If it's an expected situation, handle the situation.
>> >> > --
>> >> > Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>> >> >
>> >> >    Software Architect - Intel Open Source Technology Center
>> >> >
>> >> >       PGP/GPG: 0x6EF45358; fingerprint:
>> >> >       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
>