Now at the third system 'emerge -uvDN world' fails with: ... [ebuild U ] gnome-base/gnome-shell-3.10.3 [3.10.2.1] [ebuild R ] gnome-extra/gnome-tweak-tool-3.10.1 PYTHON_TARGETS="(-python2_6%)" The following mask changes are necessary to proceed: (see "package.unmask" in the portage(5) man page for more details) # required by net-misc/vino-3.10.1 # required by gnome-base/gnome-extra-apps-3.10.0 # required by gnome-base/gnome-3.10.0[extras] # required by @selected # required by @world (argument) # /usr/portage_leopard/profiles/package.mask: # Patrick Lauer <patrick@gentoo.org> (07 Feb 2014) # Reliably makes cryptsetup segfault, breaking boot is not acceptable =dev-libs/libgcrypt-1.6.1 At the first two systems I found that adding the line =dev-libs/libgcrypt-1.6.1 to /etc/portage/packages.unmask helped to solve the issue. But on my other systems also with vino-3.10.1 and gnome-extra-apps-3.10.0 it is not required to add this line. And I am suspicous about adding this line, because of the comment # Reliably makes cryptsetup segfault, breaking boot is not acceptable above. Any hint is appreciated.
BTW., libgcrypt was downgraded to libgcrypt-1.5.3 just some minutes ago: root@leopard:/root(34)# qlist -Iv libgcrypt dev-libs/libgcrypt-1.5.3 root@leopard:/root(35)# genlop -t libgcrypt | tail Tue Feb 4 11:06:05 2014 >>> dev-libs/libgcrypt-1.6.0-r1 merge time: 38 seconds. Wed Feb 5 04:30:21 2014 >>> dev-libs/libgcrypt-1.6.1 merge time: 39 seconds. Mon Feb 10 09:39:09 2014 >>> dev-libs/libgcrypt-1.5.3 merge time: 36 seconds.
This seems to be a subslot mishandling bug. You should not need to keep 1.6 unmasked, it should be fine to allow the downgrade to 1.5 as long as applications like vino are rebuilt afterward. vino has =dev-libs/libgcrypt-1.1.90:0= in RDEPEND, I believe it's the subslot downgrade that portage is choking on. On the emerge that's demanding libgcrypt-1.6, you may want to add --ignore-built-slot-operator-deps=y to force it to allow 1.5.
(In reply to Ben Kohler from comment #2) > This seems to be a subslot mishandling bug. You should not need to keep 1.6 > unmasked, it should be fine to allow the downgrade to 1.5 as long as > applications like vino are rebuilt afterward. vino has > =dev-libs/libgcrypt-1.1.90:0= in RDEPEND, I believe it's the subslot > downgrade that portage is choking on. > > On the emerge that's demanding libgcrypt-1.6, you may want to add > --ignore-built-slot-operator-deps=y to force it to allow 1.5. Do you mean, that I should do something like 'emerge -vuDN1 --ignore-built-slot-operator-deps=y vino gnome-extra-apps gnome'?
You should not need to unmask libgcrypt; the downgrade from libgcrypt-1.6.1 to libgcrypt-1.5.3 is supposed to have gone gracefully (at least it did so on my two systems). If "emerge -uvDN world" is telling you to downgrade libgcrypt, something probably went wrong with portage's dependency resolution mechanism. Reassigning to the portage team.
@reporter: I'd first try adding --autounmask-keep-masks. And you should _not_ use --ignore-built-slot-operator-deps. If that doesn't fix it, attach the output with --debug added. @everyone else: Please don't suggest --ignore-built-slot-operator-deps as workaround for unwanted emerge behavior.
(In reply to Alexandre Rostovtsev from comment #4) > You should not need to unmask libgcrypt; the downgrade from libgcrypt-1.6.1 > to libgcrypt-1.5.3 is supposed to have gone gracefully (at least it did so > on my two systems). > > If "emerge -uvDN world" is telling you to downgrade libgcrypt, something > probably went wrong with portage's dependency resolution mechanism. > Reassigning to the portage team. It is not a question of downgrading libgcrypt. Just now libgcrypt-1.5.3 is installed. But it looks of vino-3.10.1, gnome-extra-apps-3.10.0 or gnome-3.10.0 want to upgrade it.
(In reply to Juergen Rose from comment #6) > It is not a question of downgrading libgcrypt. Just now libgcrypt-1.5.3 is > installed. But it looks of vino-3.10.1, gnome-extra-apps-3.10.0 or > gnome-3.10.0 want to upgrade it. I see. So you had emerged vino when libgcrypt-1.6.1 was installed; vimo has an ":=" subslot dependency on libgcrypt, so the fact that it was built against subslot 20 was saved in vdb; libgcrypt-1.6.1 was masked, and libgcrypt-1.5.3 (subslot 11) was left unmasked. The expected outcome would be for the package manager to rebuild vino, since the subslot of an ":=" dependency changed. Instead, it's prompting you to unmask the version with the subslot that had been initially used to build vino. Definitely seems like a portage bug :/
I am seeing the same issue on a system without X installed. libgcrypt-1.5.3 is installed and portage wants to upgrade it to 1.6.1 and is complaining that this is masked. The following packages are causing rebuilds: (dev-libs/libgcrypt-1.6.1::gentoo, ebuild scheduled for merge) causes rebuilds for: (net-analyzer/wireshark-1.10.5::gentoo, ebuild scheduled for merge) [ebuild U ] app-misc/byobu-5.72 [5.71] USE="-screen" PYTHON_SINGLE_TARGET="python2_7 -python2_6" PYTHON_TARGETS="python2_7 -python2_6" 621 kB [ebuild U ] sys-apps/file-5.17 [5.16] USE="python zlib -static-libs" PYTHON_TARGETS="python2_7 python3_3 (-pypy2_0) -python2_6 -python3_2" 694 kB [ebuild U ] sys-devel/flex-2.5.38 [2.5.37] USE="nls -static {-test}" 1,590 kB [ebuild NS ] app-text/docbook-xml-dtd-4.4-r2:4.4 [4.1.2-r6:4.1.2, 4.2-r2:4.2] 94 kB [ebuild U ] dev-perl/Net-SSLeay-1.558 [1.550] 390 kB [ebuild U ] dev-perl/yaml-0.900.0 [0.840.0] 101 kB [ebuild r U #] dev-libs/libgcrypt-1.6.1:0/20 [1.5.3:0/11] USE="-static-libs" 0 kB [ebuild U ] dev-perl/IO-Socket-SSL-1.967.0 [1.953.0] USE="-idn" 95 kB [ebuild N ] app-text/xmlto-0.0.25 USE="-latex" 114 kB [ebuild rR ] net-analyzer/wireshark-1.10.5:0/1.10.5 USE="caps crypt filecaps ipv6 netlink pcap zlib -adns -doc -doc-pdf -geoip -gtk2 -gtk3 -kerberos -libadns -lua -portaudio -qt4 (-selinux) -smi -ssl" 0 kB [ebuild U ] dev-vcs/git-1.8.5.5 [1.8.5.4] USE="blksha1 curl gpg iconv nls pcre perl python threads webdav -cgi -cvs -doc -emacs -gnome-keyring -gtk -highlight -mediawiki (-ppcsha1) -subversion {-test} -tk -xinetd" PYTHON_SINGLE_TARGET="python2_7 -python2_6" PYTHON_TARGETS="python2_7 -python2_6" 5,206 kB [ebuild NS ] sys-kernel/hardened-sources-3.13.2-r3:3.13.2-r3 [3.8.0:3.8.0, 3.8.0-r1:3.8.0-r1, 3.8.2:3.8.2, 3.8.2-r1:3.8.2-r1, 3.8.3:3.8.3, 3.8.4:3.8.4, 3.8.4-r1:3.8.4-r1, 3.8.5:3.8.5, 3.8.6:3.8.6, 3.8.8:3.8.8, 3.8.10:3.8.10, 3.8.11:3.8.11, 3.9.2:3.9.2, 3.9.4:3.9.4, 3.9.4-r1:3.9.4-r1, 3.9.4-r2:3.9.4-r2, 3.9.5:3.9.5, 3.9.6:3.9.6, 3.9.7-r1:3.9.7-r1, 3.9.8:3.9.8, 3.10.1-r1:3.10.1-r1, 3.10.4-r2:3.10.4-r2, 3.10.5:3.10.5, 3.10.5-r1:3.10.5-r1, 3.10.7-r1:3.10.7-r1, 3.10.9-r1:3.10.9-r1, 3.10.10:3.10.10, 3.10.11:3.10.11, 3.11.3:3.11.3, 3.11.6:3.11.6, 3.11.6-r1:3.11.6-r1, 3.11.6-r2:3.11.6-r2, 3.11.7:3.11.7, 3.11.8:3.11.8, 3.11.9:3.11.9, 3.12.4:3.12.4, 3.12.5-r1:3.12.5-r1, 3.12.6-r4:3.12.6-r4, 3.12.8:3.12.8, 3.12.8-r1:3.12.8-r1, 3.13.1:3.13.1, 3.13.2-r1:3.13.2-r1] USE="-build -deblob -symlink" 777 kB [ebuild U ] sys-apps/dbus-1.8.0 [1.6.18-r1] USE="systemd -X -debug -doc (-selinux) -static-libs {-test}" 1,818 kB Total: 13 packages (9 upgrades, 1 new, 2 in new slots, 1 reinstall), Size of downloads: 11,497 kB The following mask changes are necessary to proceed: (see "package.unmask" in the portage(5) man page for more details) # required by dev-libs/libxslt-1.1.28-r1[crypt] # required by app-text/xmlto-0.0.25 # required by sys-apps/dbus-1.8.0 # required by sys-apps/systemd-208-r3 # required by app-admin/syslog-ng-3.4.7[systemd] # required by @selected # required by @world (argument) # /usr/portage/profiles/package.mask: # Patrick Lauer <patrick@gentoo.org> (07 Feb 2014) # Reliably makes cryptsetup segfault, breaking boot is not acceptable =dev-libs/libgcrypt-1.6.1
(In reply to Graham Murray from comment #8) > I am seeing the same issue [...]. Would you then please try what I asked for in comment 5? And please add your emerge --info.
This is a general problem affecting much more than just libgcrypt, it's easily visible when you try to downgrade ANY package which has reverse deps with subslot operators (when the subslot is changing, of course). *** This bug has been marked as a duplicate of bug 467774 ***
