> 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. David On Fri, Feb 20, 2015 at 9:57 PM, Albert Astals Cid <aa...@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 <thi...@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 >