Created attachment 402384 [details] emerge --info After rebuilding openssl with bindist enabled from bindist disabled, it breaks layman portage plugin (which is activated by USE-flag "sync-plugin-portage") which, apparently, relies on dev-python/cryptography to work. The emerge built with python 3.3 appears to work fine. After rebuilding dev-python/cryptography everything returns back to normal. The suggested solution therefor is to rebuild cryptography along with openssl. I forgot to save (and I could not reproduce it again, I'm sorry for that) the complete backtrace but I did save the error message: "cffi.ffiplatform.VerificationError: importing /usr/lib64/python2.7/site-packages/cryptography/_Cryptography_cffi_f3e4673fx399b1113.so: /usr/lib64/python2.7/site-packages/cryptography/_Cryptography_cffi_f3e4673fx399b1113.so: undefined symbol: EC_KEY_get_conv_form". I've attached `emerge --info` output as file since it's quite long. Here goes the info on the affected packages: [I] dev-libs/openssl Installed versions: 1.0.2a(04:52:52 PM 05/01/2015)(asm bindist tls-heartbeat zlib -gmp -kerberos -rfc3779 -sctp -static-libs -test -vanilla ABI_MIPS="-n32 -n64 -o32" ABI_PPC="-32 -64" ABI_S390="-32 -64" ABI_X86="64 -32 -x32" CPU_FLAGS_X86="sse2") [I] app-portage/layman Installed versions: 2.3.0(06:23:54 PM 02/19/2015)(bazaar cvs darcs git mercurial subversion sync-plugin-portage -g-sorcery -gpg -squashfs -test PYTHON_TARGETS="python2_7 python3_3 -pypy -python3_4") [I] dev-python/cryptography Installed versions: 0.8.2(04:38:59 PM 05/01/2015)(-test PYTHON_TARGETS="python2_7 python3_3 -pypy -python3_4") [I] sys-apps/portage Installed versions: 2.2.18(01:11:09 AM 03/31/2015)(ipc xattr -build -doc -epydoc -selinux LINGUAS="ru" PYTHON_TARGETS="python2_7 python3_3 -pypy -python3_4")
hmm, this looks like it is a hardened/cffi issue. The layman problem seems to be a downstream result where it surfaced. It looks like cryptography should have a subslot dep set for the built against openssl. Anthony can you comfirm (again) or otherwise shed light on what is needed?
It looks like the reporter *enabled* bindist, contrary to what he said. That's the only conceivable reason for that missing symbol error in cryptography's modules. Enabling bindist on openssl breaks all reverse dependencies of openssl. This is a known issue, but not one that has any reasonable solution. See bug 505306 and bug 63643. A possible solution for this case would be to add the following to dev-python/cryptography: IUSE="bindist" RDEPEND="dev-libs/openssl:0[bindist=]" However, that is quite a hack and doesn't scale well for all reverse deps of openssl. I would close this as CANTFIX.
I was speaking with the reporter in irc, they moved from USE=-bindist to USE=bindist, after which 'emerge' was no longer useable due cryptography (and layman's module that relies on it) needing a rebuild. While the widespread breakage caused by this is unfortunate, IMO it is terrible if a broken external portage module can prevent 'emerge' from running, leaving users without an obvious way to recover.
(In reply to eroen from comment #3) > While the widespread breakage caused by this is unfortunate, IMO it is > terrible if a broken external portage module can prevent 'emerge' from > running, leaving users without an obvious way to recover. The original report does not mention that this breaks portage entirely. If that that is the case, it makes this bug quite a bit more serious.
Created attachment 402630 [details] Log from #gentoo In hope of clarifying, I attach the log from an irc session predating this bug report. (Irrelevant lines are removed)
Looking at the module_spec for the laymansync module, it does a test import of layman in order to select either the native python layman api or the subprocess method to use when a sync is performed. I'll see if there is a way to not do that or delay it to the last minute before a sync.
I'm fairly sure this is solved by the :0= dep on openssl now in use, feel free to reopen if necessary.
