I have dev-python/qscintilla-python-2.3.2 installed fro quite a while, today when I've synced the tree and ran update emerge halts and complains that dev-python/qscintilla-python's dependency is not fulfilled. Reproducible: Always Steps to Reproduce: if you have dev-python/qscintilla-python-2.3.2 installed already 1. sync tree 2. deep update world Actual Results: you get this: !!! All ebuilds that could satisfy ">=dev-python/PyQt4-4.4" have been masked. !!! One of the following masked packages is required to complete your request: - dev-python/PyQt4-4.4.4-r1 (masked by: ~amd64 keyword) - dev-python/PyQt4-4.4-r1 (masked by: ~amd64 keyword) For more information, see the MASKED PACKAGES section in the emerge man page or refer to the Gentoo Handbook. (dependency required by "dev-python/qscintilla-python-2.3.2" [installed]) (dependency required by "x11-libs/qscintilla-2.3.2" [installed]) (dependency required by "dev-python/PyQt-3.17.6" [installed]) (dependency required by "media-sound/amarok-1.4.10" [installed]) (dependency required by "world" [argument]) Expected Results: no blockage should occur.
dev-python/qscintilla-python-2.3.2 is ~amd64, so a dependency on a ~amd64 package is legitimate. Either downgrade to 2.1 (I haven't checked to see if this is a good idea, it may very well be a bad one), or accept the ~amd64 keyword for one of the PyQt4-4.4 ebuilds, or add -qt4 local use flag for the package if that is acceptable. As for the reason for the change, the changelog suggests there is a build failure case without >=dev-python/PyQt4-4.4
(In reply to comment #1) > dev-python/qscintilla-python-2.3.2 is ~amd64, so a dependency on a ~amd64 > package is legitimate. Either downgrade to 2.1 (I haven't checked to see if > this is a good idea, it may very well be a bad one), or accept the ~amd64 > keyword for one of the PyQt4-4.4 ebuilds, or add -qt4 local use flag for the > package if that is acceptable. > > As for the reason for the change, the changelog suggests there is a build > failure case without >=dev-python/PyQt4-4.4 > afaik, all changes in ebuild that is in the tree should be labeled has -r# releases? right? I didn't had any build failure, searching the forums about this issue and bugzilla reviles no relevant entries, who reported this failure? going qt-4.4.0 causes too much problems.
now I can't downgrade to dev-python/qscintilla-python-2.3... Calculating dependencies... done! [nomerge ] dev-util/eric-4.2.3 LINGUAS="es -cs -de -fr -ru -tr" [ebuild UD] dev-python/qscintilla-python-2.3 [2.3.2] USE="qt4" 0 kB Total: 1 package (1 downgrade), Size of downloads: 0 kB Would you like to merge these packages? [Yes/No] y >>> Verifying ebuild manifests >>> Emerging (1 of 1) dev-python/qscintilla-python-2.3 * QScintilla-gpl-2.3.tar.gz RMD160 SHA1 SHA256 size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] >>> Unpacking source... >>> Unpacking QScintilla-gpl-2.3.tar.gz to /var/tmp/portage/dev-python/qscintilla-python-2.3/work * Applying qscintilla-python-2.2-nostrip.patch ... [ ok ] >>> Source unpacked in /var/tmp/portage/dev-python/qscintilla-python-2.3/work >>> Compiling source in /var/tmp/portage/dev-python/qscintilla-python-2.3/work/QScintilla-gpl-2.3/Python ... Error: QScintilla 2.3.2 is being used but the Python bindings 2.3 are being built. Please use matching versions. * * ERROR: dev-python/qscintilla-python-2.3 failed. * Call stack: * ebuild.sh, line 49: Called src_compile * environment, line 2406: Called die * The specific snippet of code: * ${python} configure.py ${myconf} || die "configure.py failed"; * The die message: * configure.py failed * * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/var/tmp/portage/dev-python/qscintilla-python-2.3/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/dev-python/qscintilla-python-2.3/temp/environment'. * >>> Failed to emerge dev-python/qscintilla-python-2.3, Log file: >>> '/var/tmp/portage/dev-python/qscintilla-python-2.3/temp/build.log' * Messages for package dev-python/qscintilla-python-2.3: * * ERROR: dev-python/qscintilla-python-2.3 failed. * Call stack: * ebuild.sh, line 49: Called src_compile * environment, line 2406: Called die * The specific snippet of code: * ${python} configure.py ${myconf} || die "configure.py failed"; * The die message: * configure.py failed * * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/var/tmp/portage/dev-python/qscintilla-python-2.3/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/dev-python/qscintilla-python-2.3/temp/environment'. *
We are in the process of stablizing Qt 4.4.2 and related packages, which also means PyQt4-4.4.4-r1. At the same time we will mask qt-4.3. To make sure qscintilla-python will build against the correct version of PyQt4, and guarantee a smooth upgrade path, we have upped the required version. See bug 248038. The issue was reported to me on IRC by an arch team dev, who had a build failure without the >=PyQt4-4.4 dependency. It looks like some users will hit this, but others don't. Either way, this is the way we are going. We are dropping support for Qt 4.3. For that reason I'm closing this bug as "won't fix". > afaik, all changes in ebuild that is in the tree should be labeled has > -r# releases? right? Not necessarily, it depends on the kind of change. Current ~arch users should already have the latest PyQt4 installed in combination with the latest qscintilla-python. Doing a rev-bump would needlessly force them to reinstall. For stable users, these specific versions will go stable at the same time, so again no need for a rev-bump. > going qt-4.4.0 causes too much problems Then let's solve these problems, because very soon the Qt 4.4.2 split ebuilds will be the lowest Qt4 version we will support. Let us know how we can help.
(In reply to comment #4) > We are in the process of stablizing Qt 4.4.2 and related packages, which also > means PyQt4-4.4.4-r1. At the same time we will mask qt-4.3. To make sure > qscintilla-python will build against the correct version of PyQt4, and > guarantee a smooth upgrade path, we have upped the required version. See bug > 248038. > > The issue was reported to me on IRC by an arch team dev, who had a build > failure without the >=PyQt4-4.4 dependency. It looks like some users will hit > this, but others don't. > > Either way, this is the way we are going. We are dropping support for Qt 4.3. > For that reason I'm closing this bug as "won't fix". > > > afaik, all changes in ebuild that is in the tree should be labeled has > > -r# releases? right? > > Not necessarily, it depends on the kind of change. Current ~arch users should > already have the latest PyQt4 installed in combination with the latest > qscintilla-python. Doing a rev-bump would needlessly force them to reinstall. > For stable users, these specific versions will go stable at the same time, so > again no need for a rev-bump. > > > going qt-4.4.0 causes too much problems > > Then let's solve these problems, because very soon the Qt 4.4.2 split ebuilds > will be the lowest Qt4 version we will support. Let us know how we can help. > the only combination that worked for me now is dev-python/PyQt4-4.4-r1 and dev-python/sip-4.7.6 cause using higher sip resulted in the same error, unmasking pytq4-4.4.2 resulted it huge system syste conflict.
Did you keyword all the ebuilds mentioned in bug 248038? Then you also need to mask =x11-libs/qt-4.3* which should resolve the conflicts, at least with portage >=2.1.6.
autounmask version 0.23 (using PortageXS-0.02.09 and portage-2.1.6.5) * Using repositories: /usr/portage /usr/local/portage /usr/local/enlightment * Using package.keywords file: /etc/portage/package.keywords * Using package.unmask file: /etc/portage/package.unmask * Unmasking dev-python/PyQt4-4.4.4-r1 and its dependencies.. this might take a while.. * Added '=dev-python/PyQt4-4.4.4-r1 ~amd64' to /etc/portage/package.keywords * Added '=x11-libs/qt-gui-4.4.2-r1 ~amd64' to /etc/portage/package.keywords * Added '=dev-python/sip-4.7.9' to /etc/portage/package.unmask * Added '=x11-libs/qt-opengl-4.4.2 ~amd64' to /etc/portage/package.keywords * Added '=x11-libs/qt-dbus-4.4.2 ~amd64' to /etc/portage/package.keywords * Added '=x11-libs/qt-core-4.4.2 ~amd64' to /etc/portage/package.keywords * Added '=x11-libs/qt-script-4.4.2 ~amd64' to /etc/portage/package.keywords * Added '=x11-libs/qt-qt3support-4.4.2 ~amd64' to /etc/portage/package.keywords * Added '=x11-libs/qt-sql-4.4.2 ~amd64' to /etc/portage/package.keywords [ebuild R ] sys-apps/portage-2.1.6.5 ... [ebuild U ] dev-python/sip-4.7.9 [4.7.6] ... [ebuild N ] x11-libs/qt-core-4.4.2 USE="qt3support ssl -debug -doc -glib -pch" [ebuild N ] x11-libs/qt-dbus-4.4.2 USE="-debug -pch" [ebuild N ] x11-libs/qt-script-4.4.2 USE="-debug -pch" [ebuild N ] x11-libs/qt-sql-4.4.2 USE="qt3support sqlite -debug (-firebird) -mysql -odbc -pch -postgres" [ebuild N ] x11-libs/qt-gui-4.4.2-r1 USE="accessibility cups dbus nas qt3support tiff -debug -glib -mng -nis -pch -xinerama" INPUT_DEVICES="-wacom" [ebuild N ] x11-libs/qt-qt3support-4.4.2 USE="accessibility -debug -pch" [ebuild N ] x11-libs/qt-opengl-4.4.2 USE="qt3support -debug -pch" [ebuild U ] dev-python/PyQt4-4.4.4-r1 [4.4-r1] USE="X%* dbus%* opengl%* -qt3support% -svg% -webkit%" [ebuild R ] dev-python/qscintilla-python-2.3.2 [blocks B ] x11-libs/qt-core ("x11-libs/qt-core" is blocking x11-libs/qt-4.3.4-r1) [blocks B ] <=x11-libs/qt-4.4.0_alpha:4 ("<=x11-libs/qt-4.4.0_alpha:4" is blocking x11-libs/qt-script-4.4.2, x11-libs/qt-dbus-4.4.2, x11-libs/qt-gui-4.4.2-r1, x11-libs/qt-qt3support-4.4.2, x11-libs/qt-sql-4.4.2, x11-libs/qt-core-4.4.2, x11-libs/qt-opengl-4.4.2) * Error: The above package list contains packages which cannot be * installed at the same time on the same system. ('ebuild', '/', 'x11-libs/qt-opengl-4.4.2', 'merge') pulled in by >=x11-libs/qt-opengl-4.4.2:4 required by ('ebuild', '/', 'dev-python/PyQt4-4.4.4-r1', 'merge') ('ebuild', '/', 'x11-libs/qt-core-4.4.2', 'merge') pulled in by ~x11-libs/qt-core-4.4.2 required by ('ebuild', '/', 'x11-libs/qt-qt3support-4.4.2', 'merge') >=x11-libs/qt-core-4.4.2:4 required by ('ebuild', '/', 'dev-python/PyQt4-4.4.4-r1', 'merge') ~x11-libs/qt-core-4.4.2 required by ('ebuild', '/', 'x11-libs/qt-sql-4.4.2', 'merge') (and 3 more) ('ebuild', '/', 'x11-libs/qt-dbus-4.4.2', 'merge') pulled in by ~x11-libs/qt-dbus-4.4.2 required by ('ebuild', '/', 'x11-libs/qt-gui-4.4.2-r1', 'merge') >=x11-libs/qt-dbus-4.4.2:4 required by ('ebuild', '/', 'dev-python/PyQt4-4.4.4-r1', 'merge') ('ebuild', '/', 'x11-libs/qt-4.3.4-r1', 'merge') pulled in by =x11-libs/qt-4.3*:4 required by ('ebuild', '/', 'x11-libs/qscintilla-2.3.2', 'merge') ('ebuild', '/', 'x11-libs/qt-gui-4.4.2-r1', 'merge') pulled in by ~x11-libs/qt-gui-4.4.2 required by ('ebuild', '/', 'x11-libs/qt-opengl-4.4.2', 'merge') ~x11-libs/qt-gui-4.4.2 required by ('ebuild', '/', 'x11-libs/qt-qt3support-4.4.2', 'merge') >=x11-libs/qt-gui-4.4.2:4 required by ('ebuild', '/', 'dev-python/PyQt4-4.4.4-r1', 'merge') (and 1 more) For more information about Blocked Packages, please refer to the following section of the Gentoo Linux x86 Handbook (architecture is irrelevant): http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1#blocked * Restoring files because autounmask was called with the --pretend option. * done!
Did you add =x11-libs/qt-4.3* to your package.mask?
(In reply to comment #8) > Did you add =x11-libs/qt-4.3* to your package.mask? > yes
(In reply to comment #9) > (In reply to comment #8) > > Did you add =x11-libs/qt-4.3* to your package.mask? > > > > yes > All of the above seems normal to me. This is the RDEPEND variable on qscintilla-2.3.2 RDEPEND="qt4? ( || ( x11-libs/qt-gui:4 =x11-libs/qt-4.3*:4 ) ) So the dependency is fulfilled either with qt-4.3 or qt-gui. But those two packages are blocking each other. As Ben suggested you should have =x11-libs/qt-4.3* on package.mask in order portage to remove it. In any case, by removing qt-4.3 and installing the split ebuilds should fix this issue
solved, had to unmask pyqt4 and unmerge qt-4.3 first
