When I perform 'update -uD world', my system upgrades libgcrypt from version 1.1.94 to version 1.1.12. If I perform the same action again, it wants to downgrade it back. Reproducible: Always Steps to Reproduce: 1.emerge -uD world 2.emerge -uD world 3.
Created attachment 33159 [details] emerge info
Created attachment 33160 [details] qpkq -I -v output
because of opencdk isnt it ?
vapier - yes. opencdk-0.4.5 (x86 sparc alpha hppa) DEPENDS =dev-libs/libgcrypt-1.1.12 (x86 ppc sparc alpha ia64 amd64 hppa) opencdk-0.5.1 (~x86 ppc ~sparc alpha amd64 ia64) DEPENDS =dev-libs/libgcrypt-1.1.12 (x86 ppc sparc alpha ia64 amd64 hppa) opencdk-0.5.3 (~x86 ~ppc ~sparc ~mips ~alpha amd64) DEPENDS >=dev-libs/libgcrypt-1.1.91 (x86 ~ppc amd64) So based on: fgrep KEYWORD dev-libs/libgcrypt/libgcrypt* dev-libs/libgcrypt/libgcrypt-1.1.12.ebuild:KEYWORDS="x86 ppc sparc alpha ia64 amd64 hppa" dev-libs/libgcrypt/libgcrypt-1.1.91.ebuild:KEYWORDS="x86 ~ppc amd64" dev-libs/libgcrypt/libgcrypt-1.1.92.ebuild:KEYWORDS="x86 ~amd64 ~sparc" dev-libs/libgcrypt/libgcrypt-1.1.94.ebuild:KEYWORDS="x86 ~amd64 ~sparc ~mips ~alpha" dev-libs/libgcrypt/libgcrypt-1.2.0.ebuild:KEYWORDS="~x86 ~amd64 ~sparc ~mips ~alpha ~hppa ~ia64 ~ppc" Solution 1: ~x86 mask libgcrypt-1.1.2, libgcrypt-1.1.94 (that I unmasked) Solution 2: x86 unmask opencdk-0.5.3 (added 23 Jan 2004) and optionally x86 sparc unmask opencdk-0.5.1 Does solution 2 work for you liquidx (opencdk maintainer)?
i vote for stabilizing newer opencdk since libgcrypt-1.9.x is in stable and has been for quite sometime
done - x86 opencdk-0.5.3.ebuild Is there a deeper problem with portage/repoman not being able to detect these QA flaws?
Now the same problem occurs with two packages. [ebuild UD] dev-libs/libgcrypt-1.1.12 [1.1.94] [ebuild UD] app-crypt/opencdk-0.4.5 [0.5.3] and then vice-versa.
update gnutls from 0.8.10 to 0.8.12 and that should fix it... look in the ebuild and I believe the 0.8.10 calls for a lower opencdk than the newer ebuild.
Ok I updated to gnutls-1.0.4 and opencdk-0.5.3 and that appears to of fixed the loop.
Good find Susie, I was stumped ;-). Leonid work for you?
No, but I still don't see gnutls updated at x86. It's still gnutls-0.8.10. I've tried to resync.
ok gnutls 0.8.12 and 1.0.4 x86 stable now. Any problems just repopen again.
http://packages.gentoo.org/search/?sstring=gnutls
Sorry for the previous. They both are not in x86 stable yet.
dont use packages.gentoo.org like that it doesnt get updated immediately re-open if when you *rsync* it's still not unmasked :P
http://www.gentoo.org/cgi-bin/viewcvs.cgi/net-libs/gnutls/gnutls-0.8.12.ebuild?r1=1.6&r2=1.7 I did miss 1.0.4 though. Will x86 that one when I commit a version. bump which I'm currently doing. Elaborating on packages - it is updated at periodic intervals - viewcvs is current.
It's working. Thank you, guys.
closing so it doesn't show in my open bugs list. It has been fixed after all.
