Sort of the libgcrypt pickle...:( I have 1.5.3 installed. All packages that I can manually check are fine with that version. I have masked the higher versions because they have trouble with other packages. !!! Multiple package instances within a single package slot have been pulled !!! into the dependency graph, resulting in a slot conflict: dev-libs/libgcrypt:0 (dev-libs/libgcrypt-1.5.3:0/11::gentoo, installed) pulled in by dev-libs/libgcrypt:0/11 required by (www-client/google-chrome-34.0.1847.137_p1:0/0::gentoo, ebuild scheduled for merge) ^^^^^ >=dev-libs/libgcrypt-1.2.2:0/11= required by (gnome-base/gnome-keyring-3.10.1:0/0::gentoo, installed) ^^^^^^ <dev-libs/libgcrypt-1.6.0:0[static-libs] required by (sys-power/suspend-1.0:0/0::gentoo, installed) ^ ^^^^^^^ (and 3 more with the same problems) (dev-libs/libgcrypt-1.6.1-r1:0/20::gentoo, ebuild scheduled for merge) pulled in by dev-libs/libgcrypt:0[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?] required by (media-libs/libaacs-0.7.0-r1:0/0::gentoo, ebuild scheduled for merge) ... The following keyword changes are necessary to proceed: (see "package.accept_keywords" in the portage(5) man page for more details) # required by app-crypt/gcr-3.10.1 # required by gnome-base/gnome-keyring-3.10.1 # required by gnome-base/libgnome-keyring-3.10.1 =dev-libs/libgcrypt-1.6.1-r1 ~x86 The following mask changes are necessary to proceed: (see "package.unmask" in the portage(5) man page for more details) # required by app-crypt/gcr-3.10.1 # required by gnome-base/gnome-keyring-3.10.1 # required by gnome-base/libgnome-keyring-3.10.1 # /etc/portage/package.mask: # # breaks a couple of packages Dec 18, 2013 # # suspend package is broken. cryptsetup can segfault. # =dev-libs/libgcrypt-1.6.1-r1 gcr needs ">=dev-libs/libgcrypt-1.2.2:0=", which should be met by 1.5.3 version. So, what the heck is going on here? This thing is hell bent on destroying the relative peace and calm in the portage world off late...:)
(dev-libs/libgcrypt-1.6.1-r1:0/20::gentoo, ebuild scheduled for merge) pulled in by dev-libs/libgcrypt:0[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?] required by (media-libs/libaacs-0.7.0-r1:0/0::gentoo, ebuild scheduled for merge) That's your answer. libaacs requires newer ebuild for libgcrypt that has multilib USE flags (1.5.1 doesn't have those). If you really feel like needing 1.5.1 multilib, I can do that. However, I'm CC-ing the maintainer to let him decide on the final outcome.
My goal is to not upgrade libgcrypt for now. If the multilib support is easy to add to 1.5.3, I would appreciate that. Why does the libaacs depend on the multilib use flag for libgcrypt now?
And the saga continues with other packages: dev-libs/libgcrypt:0 (dev-libs/libgcrypt-1.5.3:0/11::gentoo, installed) pulled in by dev-libs/libgcrypt:0/11 required by (www-client/google-chrome-35.0.1916.114_p1:0/0::gentoo, installed) ^^^^^ <dev-libs/libgcrypt-1.6.0:0[static-libs] required by (sys-power/suspend-1.0:0/0::gentoo, installed) ^ ^^^^^^^ dev-libs/libgcrypt:0/11= required by (net-misc/vpnc-0.5.3_p527-r1:0/0::gentoo, installed) ^^^^^^ (and 1 more with the same problems) (dev-libs/libgcrypt-1.6.1-r1:0/20::gentoo, ebuild scheduled for merge) pulled in by dev-libs/libgcrypt:0[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?] required by (net-print/cups-1.7.1-r2:0/0::gentoo, ebuild scheduled for merge) How do I fix this?
> libaacs requires newer ebuild for libgcrypt that has multilib USE flags (1.5.1 doesn't have those). This needs to be fixed in the tree, right? How can I fix this issue for good only on my side? > If you really feel like needing 1.5.1 multilib, I can do that. > However, I'm CC-ing the maintainer to let him decide on the final outcome. I think since 1.6.x is breaking some stuff and other packages in the tree are depending on the multilib USE flag for libgcrypt, I think we should add this support to the 1.5.x ebuilds in the tree.
I agree with devsk - I have the same kind of annoyance. I masked ">dev-libs/libgcrypt-1.6" because is makes sys-fs/cryptsetup unusable (bug #497654). Since that, I had several times portage insisting of unmasking libgcrypt-1.6 because portage thinks it is necessary when I want to do a @world upgrade Then I inspected carefully the "required by ...." lines and the mentioned packages, but I could not find a dependency to >=libgcrypt-1.6 somewhere. I emerged (upgraded) the newer packages few-by-few and - voila - nobody insisted any more on >=libgcrypt-1.6 Currently, I once again have the situation that @world update stops Total: 117 packages (93 upgrades, 4 new, 3 in new slots, 17 reinstalls), Size of downloads: 1,599,780 kB ... The following mask changes are necessary to proceed: (see "package.unmask" in the portage(5) man page for more details) # required by app-crypt/gcr-3.12.2 # required by gnome-base/gnome-keyring-3.12.2 # required by gnome-base/libgnome-keyring-3.12.0 # required by net-misc/networkmanager-openconnect-0.9.8.6 # required by kde-misc/networkmanagement-0.9.0.11[openconnect] # required by kde-base/solid-runtime-4.13.1[networkmanager] # required by kde-base/kdebase-runtime-meta-4.13.1 # required by kde-base/kdebase-meta-4.13.1 # required by kde-base/kde-meta-4.13.1 # required by @selected # required by @world (argument) # /etc/portage/package.mask/cryptsetup: =dev-libs/libgcrypt-1.6.1-r1 Basically, it seems to me that this behaviour of portage is quite new - let's say a year ago portage would just have ignored the packages with problems and did the @world update with the remaining packages. Today, I face the situation more and more often that @world upgrade does not run as one task, instead I have to emerge the updated packages in small groups - which gives GREAT fun! (but I dont know if this bug is the right place do discuss my observations) When my and "devsk"'s problem is the same, what kind of information should I provide to find the cause for this "try for force me to unmask =dev-libs/libgcrypt-1.6.1-r1" annoyance?
I have a feeling that its a portage bug. Its doing the same thing with cups. It wants to upgrade cups to 1.7.3 and I want to stay with the cups install I have right now (I like to print instead of chase random bugs from upgrades) and have masked versions greater than 1.7.1-r1, and that version is still in portage. Portage insists on updating to 1.7.3. Running equery depends \>=net-print/cups-1.7.3 returns all packages that depend on cups: app-admin/system-config-printer-common-1.4.3 (net-print/cups[dbus]) app-emulation/wine-1.7.19-r1 (cups ? net-print/cups) (cups ? net-print/cups[abi_x86_32]) app-office/libreoffice-4.2.4.2 (cups ? net-print/cups) app-text/ghostscript-gpl-9.14 (cups ? >=net-print/cups-1.3.8) dev-python/pycups-1.9.66 (net-print/cups) dev-qt/qtgui-4.8.5-r2 (cups ? net-print/cups) gnome-base/gnome-settings-daemon-3.10.2 (cups ? >=net-print/cups-1.4[dbus]) gnome-base/libgnomeprint-2.18.8 (cups ? >=net-print/cups-1.1.20) kde-base/print-manager-4.13.1 (>=net-print/cups-1.5.0[dbus]) net-fs/samba-3.6.23 (cups ? net-print/cups) net-misc/freerdp-1.1.0_beta1_p20130710 (cups ? net-print/cups) net-print/foomatic-filters-4.0.17-r1 (cups ? >=net-print/cups-1.6.0) net-print/gutenprint-5.2.9 (cups ? >=net-print/cups-1.1.14) net-print/libgnomecups-0.2.3-r3 (>=net-print/cups-1.3.8) net-wireless/bluez-5.18-r1 (cups ? net-print/cups) www-client/google-chrome-35.0.1916.114_p1 (net-print/cups) x11-libs/gtk+-2.24.23 (cups ? net-print/cups) x11-libs/gtk+-3.10.8 (cups ? >=net-print/cups-1.2) None of which requires net-print/cups-1.7.3. So, what's going on here?
One thing in common to both cups-1.7.3 and libgcrypt-1.6.1-r1, which is not present in older ebuilds, is this check: abi_x86_32? ( !<=app-emulation/emul-linux-x86-baselibs-20131008-r19 !app-emulation/emul-linux-x86-baselibs[-abi_x86_32] Is this somehow forcing the upgrade?
As per --tree, [ebuild U ] x11-libs/gtk+-2.24.23-r1:2 [2.24.23:2] USE="cups introspection (-aqua) -debug -examples {-test} -vim-syntax -xinerama" 0 kB [ebuild U ] net-print/cups-1.7.3 [1.7.1-r1] USE="X acl dbus gnutls java pam python ssl threads usb zeroconf -debug -kerberos -lprng-compat (-selinux) -static-libs -systemd -xinetd" LINGUAS="-ca -es -fr -it -ja -pt_BR% -ru" PYTHON_SINGLE_TARGET="python2_7 (-python2_6)" PYTHON_TARGETS="python2_7 (-python2_6)" 8,587 kB gtk+-2.24.23-r1: cups? ( net-print/cups:=[${MULTILIB_USEDEP}] )
Any comments anyone? This one is a sort of blocker (no pun intended) for me.
Multilib packages require the newer version (the abi_* flags on libgcrypt etc.).
Why in the world would you close the bug? If the newer revisions are required, the devs have to provide the new revisions. Users can't do that.
BTW, I am using the pure x86 and don't even need multilib. What can I do to get past this issue (anything other than upgrade to libgcrypt-1.6.1 and upgrade to cups-1.7.3)?
(In reply to devsk from comment #11) > Why in the world would you close the bug? The bug says that 'nothing needs the higher versions'. I explained to you what needs them, and therefore invalidated the statement in the bug. Do you need anything else? > If the newer revisions are required, the devs have to provide the new > revisions. Users can't do that. And they are in the tree. If you mask them... errr...
(In reply to Michał Górny from comment #13) > (In reply to devsk from comment #11) > > Why in the world would you close the bug? > > The bug says that 'nothing needs the higher versions'. I explained to you > what needs them, and therefore invalidated the statement in the bug. Do you > need anything else? > > > If the newer revisions are required, the devs have to provide the new > > revisions. Users can't do that. > > And they are in the tree. If you mask them... errr... I don't see 1.5.3-rX with multilib support. What is multilib support? Why do I care about it in a pure x86 profile?
Because it is normal for newer versions of packages to require newer versions of other packages. And for old packages to get removed or otherwise become unsupported over time. If you have problems with newer versions of software, please open proper bugs for particular packages so that the bugs could be eventually fixed.
Can you please tell me what am I supposed to do until suspend dumping core is fixed (in case I upgrade to libgcrypt-1.6.1-r1)? There is a reason why I am masking libgcrypt-1.6.1. Also: portage seems to be trying to upgrade cups to net-print/cups-1.7.3 when there is no abi_* variable involved. Its upgrading to ~x86 when I have specifically marked that package to be -~x86. cups is involved in 2 deps: First: [nomerge ] app-text/gtkspell-3.0.4:3/0 USE="introspection -vala" [ebuild U ] x11-libs/gtk+-3.12.2:3 [3.10.8:3] USE="X cups introspection (-aqua) -cloudprint% -colord -debug -examples {-test} -vim-syntax -wayland -xinerama (-packagekit%)" 14,664 kB [ebuild U ] x11-libs/gtk+-2.24.23-r1:2 [2.24.23:2] USE="cups introspection (-aqua) -debug -examples {-test} -vim-syntax -xinerama" 0 kB [ebuild U ] net-print/cups-1.7.3 [1.7.1-r1] USE="X acl dbus gnutls java pam python ssl threads usb zeroconf -debug -kerberos -lprng-compat (-selinux) -static-libs -systemd -xinetd" LINGUAS="-ca -es -fr -it -ja -pt_BR% -ru" PYTHON_SINGLE_TARGET="python2_7 (-python2_6)" PYTHON_TARGETS="python2_7 (-python2_6)" x11-libs/gtk+ is also not supposed to be going to x11-libs/gtk+-2.24.23-r1:2 because x11-libs/gtk+-2.24.23-r1:2 is ~x86. Portage tells me I need to add ~x86 to the keywords for gtk+ to complete world update. If I only emerge gtk+:2, only stable version x11-libs/gtk+-2.24.23:2 is emerged. Second: [nomerge ] app-office/libreoffice-4.2.4.2 USE="branding cups dbus gnome gtk gtk3 java kde mysql opengl vba vlc webdav (-aqua) -bluetooth -debug -eds -firebird -gstreamer -jemalloc -odk -postgres -telepathy {-test}" LIBREOFFICE_EXTENSIONS="-nlpsolver -scripting-beanshell -scripting-javascript -wiki-publisher" PYTHON_SINGLE_TARGET="python2_7 -python3_3" PYTHON_TARGETS="python2_7 -python3_3" [nomerge ] net-print/cups-1.7.3 [1.7.1-r1] USE="X acl dbus gnutls java pam python ssl threads usb zeroconf -debug -kerberos -lprng-compat (-selinux) -static-libs -systemd -xinetd" LINGUAS="-ca -es -fr -it -ja -pt_BR% -ru" PYTHON_SINGLE_TARGET="python2_7 (-python2_6)" PYTHON_TARGETS="python2_7 (-python2_6)" This is a straight dep : cups? ( net-print/cups ) libgcrypt upgrade is happening because of cups also. I am not convinced that the problem is because of multilib flags alone.
I removed the gnutls USE for cups and that got rid of dependency emanating from needing the multilib version of libgcrypt. But that was not the root cause of the issue. The root cause it appears is that portage is trying to upgrade to ~x86 version of the cups package when I have keyworded the package to be x86 only. libgcrypt was getting pulled because of cups upgrade. Please help me understand this: A is ~x86. It depends on B which is marked x86, and its a direct dep without any multilib/abi voodoo. Why is portage asking to upgrade B to a ~x86 version while upgrading A? That does not make sense. [nomerge ] media-video/gnome-mplayer-1.0.9 USE="alsa dbus dconf gnome ipod libnotify musicbrainz pulseaudio -gda" [nomerge ] x11-libs/libnotify-0.7.6 USE="introspection {-test}" [nomerge ] virtual/notification-daemon-0 USE="gnome" [nomerge ] x11-misc/notification-daemon-0.7.6 [ebuild U ] x11-libs/gtk+-3.12.2:3 [3.10.8:3] USE="X cups introspection (-aqua) -cloudprint% -colord -debug -examples {-test} -vim-syntax -wayland -xinerama (-packagekit%)" 14,664 kB [ebuild U ] x11-libs/gtk+-2.24.23-r1:2 [2.24.23:2] USE="cups introspection (-aqua) -debug -examples {-test} -vim-syntax -xinerama" 0 kB [ebuild U ] net-print/cups-1.7.3 [1.7.1-r1] USE="X acl dbus java pam python ssl threads usb zeroconf -debug -gnutls* -kerberos -lprng-compat (-selinux) -static-libs -systemd -xinetd" LINGUAS="-ca -es -fr -it -ja -pt_BR% -ru" PYTHON_SINGLE_TARGET="python2_7 (-python2_6)" PYTHON_TARGETS="python2_7 (-python2_6)" x11-misc/notification-daemon-0.7.6 is ~x86 and is pulling gtk+:3 up: RDEPEND=">=dev-libs/glib-2.28 x11-libs/gtk+:3 No multilib/abi voodoo there. So, why is this upgrade of gtk+:3 (and hence cups) needed? This behaviour has changed in recent times. It was not like this before.
1) If you want portage to stop unmasking stuff, use --autounmask-keep-masks. 2) For any other question we'll need a (compressed) debug log: emerge <your options> --debug &> debug.log
Unfortunately, I got so sick with this crap that I removed the gnutls from USE for cups and accepted the cups upgrade. It was just too much for me to take blocking all other stuff from being upgrading. So, I can't generate the debugs you need now. I will provide that info once I get in next upgrade cycle. The bug goes into NEEDINFO.
