make[1]: Entering directory `/var/tmp/portage/dev-qt/qtsvg-5.1.0_rc1/work/qtsvg-opensource-src-5.1.0-rc1_build/tests/auto/qsvgrenderer' LD_LIBRARY_PATH=/var/tmp/portage/dev-qt/qtsvg-5.1.0_rc1/work/qtsvg-opensource-src-5.1.0-rc1_build/lib:/usr/lib64${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH} '/var/tmp/portage/dev-qt/qtsvg-5.1.0_rc1/work/qtsvg-opensource-src-5.1.0-rc1_build/gentoo-testrunner' ./tst_qsvgrenderer make[1]: Entering directory `/var/tmp/portage/dev-qt/qtsvg-5.1.0_rc1/work/qtsvg-opensource-src-5.1.0-rc1_build/tests/auto/qsvgdevice' LD_LIBRARY_PATH=/usr/lib64${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH} '/var/tmp/portage/dev-qt/qtsvg-5.1.0_rc1/work/qtsvg-opensource-src-5.1.0-rc1_build/gentoo-testrunner' ./tst_qsvgdevice make[1]: Entering directory `/var/tmp/portage/dev-qt/qtsvg-5.1.0_rc1/work/qtsvg-opensource-src-5.1.0-rc1_build/tests/auto/qsvggenerator' LD_LIBRARY_PATH=/var/tmp/portage/dev-qt/qtsvg-5.1.0_rc1/work/qtsvg-opensource-src-5.1.0-rc1_build/lib:/usr/lib64${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH} '/var/tmp/portage/dev-qt/qtsvg-5.1.0_rc1/work/qtsvg-opensource-src-5.1.0-rc1_build/gentoo-testrunner' ./tst_qsvggenerator No protocol specified QXcbConnection: Could not connect to display :0 /var/tmp/portage/dev-qt/qtsvg-5.1.0_rc1/work/qtsvg-opensource-src-5.1.0-rc1_build/gentoo-testrunner: line 4: 4864 Aborted "$@" make[1]: *** [check] Error 134 make[1]: Leaving directory `/var/tmp/portage/dev-qt/qtsvg-5.1.0_rc1/work/qtsvg-opensource-src-5.1.0-rc1_build/tests/auto/qsvgrenderer' make: *** [sub-qsvgrenderer-check] Error 2 make: *** Waiting for unfinished jobs.... No protocol specified QXcbConnection: Could not connect to display :0 /var/tmp/portage/dev-qt/qtsvg-5.1.0_rc1/work/qtsvg-opensource-src-5.1.0-rc1_build/gentoo-testrunner: line 4: 4867 Aborted "$@" make[1]: *** [check] Error 134 make[1]: Leaving directory `/var/tmp/portage/dev-qt/qtsvg-5.1.0_rc1/work/qtsvg-opensource-src-5.1.0-rc1_build/tests/auto/qsvgdevice' make: *** [sub-qsvgdevice-check] Error 2 make[1]: Entering directory `/var/tmp/portage/dev-qt/qtsvg-5.1.0_rc1/work/qtsvg-opensource-src-5.1.0-rc1_build/tests/auto/qicon_svg' LD_LIBRARY_PATH=/usr/lib64${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH} '/var/tmp/portage/dev-qt/qtsvg-5.1.0_rc1/work/qtsvg-opensource-src-5.1.0-rc1_build/gentoo-testrunner' ./tst_qicon_svg No protocol specified QXcbConnection: Could not connect to display :0 /var/tmp/portage/dev-qt/qtsvg-5.1.0_rc1/work/qtsvg-opensource-src-5.1.0-rc1_build/gentoo-testrunner: line 4: 4868 Aborted "$@" make[1]: *** [check] Error 134 make[1]: Leaving directory `/var/tmp/portage/dev-qt/qtsvg-5.1.0_rc1/work/qtsvg-opensource-src-5.1.0-rc1_build/tests/auto/qsvggenerator' make: *** [sub-qsvggenerator-check] Error 2 No protocol specified QXcbConnection: Could not connect to display :0 /var/tmp/portage/dev-qt/qtsvg-5.1.0_rc1/work/qtsvg-opensource-src-5.1.0-rc1_build/gentoo-testrunner: line 4: 4870 Aborted "$@" make[1]: *** [check] Error 134 make[1]: Leaving directory `/var/tmp/portage/dev-qt/qtsvg-5.1.0_rc1/work/qtsvg-opensource-src-5.1.0-rc1_build/tests/auto/qicon_svg' make: *** [sub-qicon_svg-check] Error 2 * ERROR: dev-qt/qtsvg-5.1.0_rc1 failed (test phase): * emake failed
With 5.3.0_rc, turning on virtual X eliminates the errors in comment #0 but there is the following output: Detecting CXX compiler ABI info - done CMake Error at /var/tmp/portage/dev-qt/qtsvg-5.3.0_rc/work/qtsvg-opensource-src-5.3.0-RC_build/lib/cmake/Qt5Svg/Qt5SvgConfig.cmake:27 (message): The imported target "Qt5::Svg" references the file "/var/tmp/portage/dev-qt/qtsvg-5.3.0_rc/work/qtsvg-opensource-src-5.3.0-RC_build/include/qt5/" but this file does not exist. Possible reasons include: * The file was deleted, renamed, or moved to another location. * An install or uninstall procedure did not complete successfully. * The installation package was faulty and contained "/var/tmp/portage/dev-qt/qtsvg-5.3.0_rc/work/qtsvg-opensource-src-5.3.0-RC_build/lib/cmake/Qt5Svg/Qt5SvgConfig.cmake" but not all the files it references. Call Stack (most recent call first): /var/tmp/portage/dev-qt/qtsvg-5.3.0_rc/work/qtsvg-opensource-src-5.3.0-RC_build/lib/cmake/Qt5Svg/Qt5SvgConfig.cmake:62 (_qt5_Svg_check_file_exists) CMakeLists.txt:15 (find_package) Configuring Configuring incomplete, errors occurred! See also "/var/tmp/portage/dev-qt/qtsvg-5.3.0_rc/work/qtsvg-opensource-src-5.3.0-RC_build/tests/auto/cmake/build/module_includes/build/CMakeFiles/CMakeOutput.log". 0% tests passed, 1 tests failed out of 1 Total Test time (real) = 0.43 sec The following tests FAILED: 1 - module_includes (Failed) Errors while running CTest make[1]: *** [check] Error 8 make[1]: Leaving directory `/var/tmp/portage/dev-qt/qtsvg-5.3.0_rc/work/qtsvg-opensource-src-5.3.0-RC_build/tests/auto/cmake' make: *** [sub-cmake-check] Error 2 * __helpers_die: WARNING: emake failed Additionally there's probably an error in our virtual X code because portage doesn't treat the test as failed.
(In reply to Michael Palimaka (kensington) from comment #1) All the paths in $D look wrong... anyway, these tests require cmake installed right? In that case I'm not sure how to handle the dependency (see also bug 457182)
(In reply to Davide Pesavento from comment #2) > All the paths in $D look wrong... anyway, these tests require cmake > installed right? In that case I'm not sure how to handle the dependency (see > also bug 457182) It would appear so, but that's not restricted to tests - it looks like every Qt module generates files for consumption by cmake (eg. /usr/lib64/cmake/Qt5Core/Qt5CoreConfig.cmake)
(In reply to Michael Palimaka (kensington) from comment #3) > (In reply to Davide Pesavento from comment #2) > > All the paths in $D look wrong... anyway, these tests require cmake > > installed right? In that case I'm not sure how to handle the dependency (see > > also bug 457182) > > It would appear so, but that's not restricted to tests - it looks like every > Qt module generates files for consumption by cmake (eg. > /usr/lib64/cmake/Qt5Core/Qt5CoreConfig.cmake) Yep, but those files are not generated by cmake, but by the qt buildsystem itself with some qmake trickery. IOW, cmake is not a dependency at build time, unless tests are enabled, in which case cmake/ctest are used during src_test(). So, either we add the dependency and fix those tests, or we disable all tests that require cmake.
I think we should punt the cmake-based tests. The test does find_package(Qt5Foo), calling Qt5FooConfig.cmake: set(_Qt5Foo_OWN_INCLUDE_DIRS "${_qt5Foo_install_prefix}/include/qt5/" "${_qt5Foo_install_prefix}/include/qt5/QtFoo") foreach(_dir ${_Qt5Foo_OWN_INCLUDE_DIRS}) _qt5_Foo_check_file_exists(${_dir}) endforeach() Even though install_prefix is set to the build dir for the test, it fails because the include/qt5 subdirectory isn't created until install time.
(In reply to Michael Palimaka (kensington) from comment #5) > I think we should punt the cmake-based tests. > Yeah I agree. > Even though install_prefix is set to the build dir for the test, it fails > because the include/qt5 subdirectory isn't created until install time. Assuming that with "install time" you mean src_install, then the paths are still wrong, because the build dir is somewhere under $WORKDIR, while the install destination is $D.
Created attachment 381498 [details, diff] disable-test.patch Happy with this patch?
That sed expression only matches in qtbase, qtsensors, qtserialport, qtx11extras. I suppose all modules are affected by this problem...?
Right, that's unfortunate...I don't suppose there's any qmake argument to override? Safe to just punt any instance of 'cmake' in the file?
(In reply to Michael Palimaka (kensington) from comment #9) > Right, that's unfortunate...I don't suppose there's any qmake argument to > override? 'qmake [...] -after SUBDIRS-=cmake' is worth trying. > Safe to just punt any instance of 'cmake' in the file? No, way too risky IMO. Actually, some repos such as qtbase also have a installed_cmake test subdir, do you know what that is? Should we remove it too? In either case, matching only 'cmake' looks wrong to me.
Created attachment 381664 [details, diff] disable-test.patch Revised patch. One module would require an extra patch to remove a custom test target. I wonder if we should just restrict tests (at least for certain modules)...they seem to be mostly broken in one way or another.
(In reply to Michael Palimaka (kensington) from comment #11) > Created attachment 381664 [details, diff] [details, diff] > disable-test.patch > > Revised patch. One module would require an extra patch to remove a custom > test target. ACK, go ahead please. > > I wonder if we should just restrict tests (at least for certain > modules)...they seem to be mostly broken in one way or another. I intend to fix tests, but it's a low priority task for me at the moment. I guess for now we can restrict them globally in the eclass, and revisit the issue after the move to gx86.
The patch has since been applied, and tests pass.
