El Diumenge, 1 de març de 2015, a les 23:15:36, David Rosca va escriure: > 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)?
playground repos are basically "free for all" > Would it be ok for a Bluedevil (in workspace) to depend on a library > in playground? Seems not ideal to me, playground is supposed to be "non stable stuff" and making our releases depend on that sends the wrong signal. > 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? It's probably better if you have a branch ready, but i think the official releases (i.e. master) should only get to depend on it once BluezQt has been released officially (either as part of KDE Frameworks or as a independent lib). Best Regards, Albert > > Thanks, > David > > On Sat, Feb 21, 2015 at 1:36 AM, Albert Astals Cid <aa...@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 <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