From Markos report: Tests fail for kdevelop 65% tests passed, 7 tests failed out of 20 Total Test time (real) = 18.18 sec The following tests FAILED: 6 - duchaintest (Failed) 8 - cppcodecompletiontest (Failed) 9 - cppcodegentest (Failed) 16 - cmakeprojectvisitortest (Failed) 18 - cmakeloadprojecttest (Failed) 19 - gdbtest (Failed) 20 - qtprinters (Failed) Errors while running CTest Restricting for now.
Created attachment 264849 [details] test log for kdevelop-4.2.0 Status as of 4.2.0: * 4 of 22 tests fail with X and DBUS * Several tests bring up windows and/or start other programs, i.e. will have to be disabled Test log attached
*** Bug 366471 has been marked as a duplicate of this bug. ***
4.2.3: The following tests FAILED: 2 - parsertest (Failed) 10 - cppcodegentest (Failed) 17 - cmakeprojectvisitortest (Failed) 20 - cmakemanagertest (Failed) 21 - gdbtest (Failed) 22 - qtprinters (Failed) Tests pop up dialog box.
Created attachment 295401 [details] test log for kdevelop-4.2.3
Created attachment 307095 [details] kdevelop-4.3.0-lasttest.log For 4.3.0, there are two tests that hang and timeout (I'm guessing they timeout because they say that time to completion was 1500 seconds, one looks like it failed trying to invoke knotify and I'm not sure why the other timed out). Tests that timeout are parsertest and gdbtest, and I guess they're showing as failed because they timed out. Additionally, qtprinters fails all but two of the tests, the failures have something to do with GDB. LastTest.log attached.
FAIL! : GDBDebugger::QtPrintersTest::testQString() 'gdb.execute("print s").contains("\"test string\"")' returned FALSE. () Loc: [/var/tmp/portage/dev-util/kdevelop-4.3.0/work/kdevelop-4.3.0/debuggers/gdb/printers/tests/qtprinters.cpp(93) is suspicious. (4.3.0-) presumably contains("\"test string\"") reads as \test string\ It seems as if it may have regressed to a Windows folder format, instead of /test string/. If you're keen have a closer look in qtprinters.cpp. However, it's a test fail, and inevitably that leads to RESTRICT, doesn't it? Curiously this test suite started out by effectively connecting to a dbus session. Wonders never cease.
> presumably contains("\"test string\"") reads as \test string\ > It seems as if it may have regressed to a Windows folder format, instead of > /test string/. Ian, "\"test string\"" reads as "test string". Please first think then comment.
Tests are restricted and we have decided that it's not currently useful to track this issue.