>>> Emerging (1 of 1) app-portage/layman-2.3.0::gentoo * layman-2.3.0.tar.gz SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ] >>> Unpacking source... >>> Unpacking layman-2.3.0.tar.gz to /var/tmp/portage/app-portage/layman-2.3.0/work >>> Source unpacked in /var/tmp/portage/app-portage/layman-2.3.0/work >>> Preparing source in /var/tmp/portage/app-portage/layman-2.3.0/work/layman-2.3.0 ... python setup.py setup_plugins !!! Layman API imports failed.Traceback (most recent call last): File "setup.py", line 12, in <module> from layman.version import VERSION File "./layman/__init__.py", line 13, in <module> from layman.api import LaymanAPI File "./layman/api.py", line 25, in <module> from layman.remotedb import RemoteDB File "./layman/remotedb.py", line 46, in <module> from sslfetch.connections import Connector ImportError: No module named 'sslfetch' Reproducible: Always
2 options, Since ssl-fetch is likely merged now, just re-emerge layman-2.3.0. I have already fixed DEPENDS to ensure ssl-fetch is merged before layman is started. If you re-sync the ebuild has been fixed.
I have dev-python/ssl-fetch-0.3 installed, but layman still won't build due to this error.
*** Bug 539966 has been marked as a duplicate of this bug. ***
(In reply to PM from comment #2) > I have dev-python/ssl-fetch-0.3 installed, but layman still won't build due > to this error. This seems odd/unlikely. Can you attach a full build.log for layman-2.3.0 and a comment with the output of "qlist ssl-fetch"?
OK, I can reproduce the error when the eselected python version doesn't not match a python version in PYTHON_COMPAT for ssl-fetch and layman. I'll work on a fix. BUT you should be running a common list of python versions to install portage, layman, and other portage tools into. Plus you should have one of those versions eselected for normal operations. eselect a non-standard version for certain development testing reasons for some other app, then reset it back.
Yeah, I wasn't aware python 3.4 is still "experimental" or something. Switching to 3.3 by eselect fixed this issue.
Python 3.4 is not experimental, it is stable for many arches already. The problem was you were running py-3.4 but ssl-fetch was not installed to py-3.4 and layman was not set to install to 3.4. You should set all portage tools to the same PYTHON_TARGETS list that you install portage to to avoid these types of problems. But like I said, I'll work on a solution that avoids the issue you encountered.
A possible (todo) fix would be to automatically detect PYTHON_TARGETS (and RUBY_TARGETS). Setting those manually would be supported for special cases. This would avoid future issues like that and simplify setting some things up (single target would still be a thing, obviously). This would prevent future possible issues like this.
No, the solution has been committed to git already. I've moved a master api class out of the init so that it does not cause it to merge all the other modules, just because it wanted to import the version. The next layman release should not have that same problem. To work around the problem for the current layman-2.3.0, make sure you have eselected a python version that layman/ssl-fetch is installing it's modules to.
ssl-fetch does not appear to support python-3.4. I see this message at the end of the build: * Building package for python3.3 only while python3.4 is active. * Please consider switching the active Python 3 interpreter: * * eselect python set --python3 python3.3 * * Please note that after switching the active Python interpreter, * you may need to run 'python-updater' to rebuild affected packages. * * For more information on PYTHON_TARGETS and python.eclass * compatibility, please see the relevant Wiki article [1]. Since py-3.4 has been stable for a while now, any word on when ssl-fetch can build to it?
All ssl-fetch ebuilds have 3.4 enabled and is installed to it on my system. PYTHON_COMPAT=(python{2_7,3_3,3_4} pypy) Perhaps you have a package.mask entry for it somewhere. Please show your "emerge --info ssl-fetch"
It's been two years since this bug has been open. We're well past the point of SSLFetch not being stable or widely used enough. I'm closing this out.
