checking unicode/ubrk.h presence... yes checking for unicode/ubrk.h... yes checking for PANGO... yes checking for GNOME_KEYRING... yes checking for LIBEXIF... yes checking for TAGLIB... yes checking for ENCA... yes checking for LIBXML2... yes configure: error: Couldn't find Qt >= 4.7.1. cave show qt-gui * x11-libs/qt-gui ::gentoo 4.6.2 4.6.2-r1(~) 4.6.3 4.6.3-r2 4.7.0-r1(~) 4.7.1-r1(~) 4.7.2(~)* {:4} ::installed 4.7.2 {:4}
Created attachment 267453 [details] build log Build log
Created attachment 267455 [details] configure.log for failure
It's an ebuild bug. gtk USE flag sends the configure script a --enable-gdkpixbuf and the qt4 USE flag sends it a --enable-qt. These configure flags are mutually exclusive in the build system (see below): ################################################################## # Check for tracker-extract: Choose between GdkPixbuf/Qt ################################################################## if test "x$enable_qt" != "xno" && test "x$enable_gdkpixbuf" != "xyes"; then PKG_CHECK_MODULES(QT, [QtGui >= $QT_REQUIRED], [have_qt=yes], [have_qt=no]) AC_MSG_ERROR([have_qt=$have_qt]) TRACKER_EXTRACT_CFLAGS="$TRACKER_EXTRACT_CFLAGS $QT_CFLAGS" TRACKER_EXTRACT_LIBS="$TRACKER_EXTRACT_LIBS $QT_LIBS" if test "x$have_qt" = "xyes"; then AC_DEFINE(HAVE_QT, [], [Define if we have Qt]) selected_for_albumart="yes (qt)" fi else have_qt="no (disabled)" fi if test "x$enable_qt" = "xyes"; then if test "x$have_qt" != "xyes"; then AC_MSG_ERROR([Couldn't find Qt >= $QT_REQUIRED.]) fi fi As you should be able to see, if 'enable_qt' is 'yes' and 'enable_gdkpixbuf' is 'yes', the condition above will not be entered, qt will _not_ be checked for (pkg_check_modules), and the small part at the end will pop up an error message stating that it cannot find qt. I'm going to propose an ebuild patch in a little bit that should fix this issue (if both qt4 and gtk are USE-flag enabled, do not pass a --enable-gdkpixbuf to the configure script), or you can simply disable the 'gtk' USE flag (or the 'qt4' USE flag) to get around this for now.
Created attachment 267831 [details, diff] ebuild patch to allow tracker to compile with both gtk and qt4 support
What your explanation, you can conclude this is an actual upstream bug for doing checks in the wrong place. The ebuild can work it around obviously but I don't think it's a good solution.
Actually, it looks to me that the two options are intended to be mutually exclusive (hence why I included the commented section above the configure.ac code to check for qt). They claim that they are using that to "Choose between GdkPixbuf/Qt". Granted, it would have been better if they had put out an error message that matched the context (something like "cannot use both qt and gdkpixbuf" instead of "Couldn't find Qt >= 4.7.1."), but the ebuild should be smart enough to avoid these sorts of issues. Currently, if both USE flags are enabled, the configure script crashes and burns because enabling the gtk USE flag sets the --enable-gdkpixbuf configure switch. All I'm proposing is that if the qt4 USE flag is set, do not set the --enable-gdkpixbuf configure switch.
How about using EAPI-4 and REQUIRED_USE=" gtk? ( !qt4 ) qt4? ( !gtk ) " It's also easier to revert (just remove REQUIRED_USE block) when it's fixed upstream.
Because gtk and qt for the most part operate just fine together in the build - it's gdkpixbuf+qt4 that does not. Disabling gtk is not the right approach, but the gdkpixbuf switch is tied to the gtk USE flag. I'd rather not needlessly disable the gtk USE flag (and numerous --enable switches) just to disable the gdkpixbuf switch.
agreed, I'll apply your patch asap.
+*tracker-0.10.6 (03 Apr 2011) + + 03 Apr 2011; Gilles Dartiguelongue <eva@gentoo.org> tracker-0.10.5.ebuild, + +tracker-0.10.6.ebuild, tracker-9999.ebuild: + Version bump. Fix qt4 handling, bug #360839. I went with a slightly different approach, but it should work just fine. Feel free to reopen if this is not fixed. Thanks for reporting.
