Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
^^
*** Bug 206787 has been marked as a duplicate of this bug. ***
*** Bug 206983 has been marked as a duplicate of this bug. ***
My problem is the same as bug#206787 (marked as dup of this bug) * * ERROR: app-misc/strigi-0.5.7 failed. * Call stack: * ebuild.sh, line 46: Called pkg_setup * strigi-0.5.7.ebuild, line 48: Called built_with_use 'pkg_setup' 'pkg_setup' * eutils.eclass, line 1694: Called die * The specific snippet of code: * die) die "$PKG does not actually support the $1 USE flag!";; * The die message: * x11-libs/qt-4.4.0_rc1 does not actually support the dbus USE flag! * except the package complaining is app-misc/strigi-0.5.7 instead of soprano when trying to emerge kde-4. If further info needed let me know :-0
I had the same problem here and found a dirty hack to get around. IMHO the trouble seems to come from the "split ebuilds" of qt-4. I did the following steps: 1. faked the provided USE flags of the qt-4 package: mkdir -p /usr/local/portage/x11-libs cd /usr/local/portage/x11-libs cp -a /usr/portage/x11-libs/qt . cd qt nano -w qt-4.4.0_rc1.ebuild changed -> IUSE="opengl qt3support" into -> IUSE="opengl qt3support accessibility dbus debug gif jpeg png ssl zlib" 2. now I autounmask'ed and tried to build kdelibs like before, including all dependencies, especially the various qt-xyz packages. The build failed, probably due to the lack of features in the generated qt install, but portage now thinks that the qt dependencies are successfully installed. 3. trown away the broken qt stuff: cd /usr/lib mv qt4 qt4-broken 4. then I built qt4 on my own, using the configure options that I copied from "emerge qt-core", but with less "-noxxx" options: cd /var/tmp tar -xvzf /usr/portage/distfiles/qt-x11-preview-opensource-src-4.4.0-tp1.tar.gz cd qt-x11-preview-opensource-src-4.4.0-tp1 ./configure -debug -stl -verbose -largefile \ -confirm-license -no-rpath \ -prefix /usr \ -bindir /usr/bin \ -libdir /usr/lib/qt4 \ -datadir /usr/share/qt4 \ -docdir /usr/share/doc/qt-4.4.0_rc1 \ -headerdir /usr/include/qt4 \ -plugindir /usr/lib/qt4/plugins \ -sysconfdir /etc/qt4 \ -translationdir /usr/share/qt4/translations \ -examplesdir /usr/share/qt4/examples \ -demosdir /usr/share/qt4/demos \ -fast -reduce-relocations \ -nomake examples -nomake demos \ -openssl -glib -qt3support make make install 5. after that I was able to successfully emerge kdelibs and so on, the whole "kde-meta" emerged fine.
*** Bug 210071 has been marked as a duplicate of this bug. ***
confirming bug
CCing qt aswell as since this is partly a problem with x11-libs/qt-* features being overridden by x11-libs/qt-core. Ex: x11-libs/qt-gui with USE accessibility emerges fine but x11-libs/qt-core has #define QT_NO_ACCESSIBILITY in /usr/include/qt4/Qt/qfeatures.h hence KDE fails.
(In reply to comment #7) > CCing qt aswell as since this is partly a problem with x11-libs/qt-* features > being overridden by x11-libs/qt-core. > Ex: x11-libs/qt-gui with USE accessibility emerges fine but x11-libs/qt-core > has #define QT_NO_ACCESSIBILITY in /usr/include/qt4/Qt/qfeatures.h hence KDE > fails. > It's not only the accessibility. You also get trouble when qt-core is not built with X Session Management (-no-sm). I propose to put a USE-Flag "X" (probably also one for "accessibility") to qt-core, to enable the neccessary configuration for building kde4 correctly. If you want to keep qt-core clean from X-deps (server-usage) this must (in my eyes) be done optional - with USE-Flags. As the way to finish building qt is quite long it would be great when at least qt-core tells the user in a nice Warning, that he MUST build qt-core with these USE-Flags, when he/she wants to build kde4. Or is it possible yet to cancel a "emerge kde4" when qt-core does not have these neccessary flags enabled?
KDE 4.0.2 now compiles fine with Qt 4.4, marking as FIXED.