Summary: | sys-apps/portage-2.1.8.3 - AttributeError: 'module' object has no attribute 'autouse' | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Ricardo I. Vieitez <gentoo.bugzilla> |
Component: | Core | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | esigra, jer |
Priority: | High | Keywords: | InVCS |
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 335925 | ||
Attachments: |
What happens when building dev-lang/php
What happens building dev-lang/python-2.6.5-r3 |
Description
Ricardo I. Vieitez
2010-07-31 18:24:35 UTC
Created attachment 240863 [details]
What happens when building dev-lang/php
Created attachment 240865 [details]
What happens building dev-lang/python-2.6.5-r3
What's your active python version and why are you running an old portage svn version? Try installing a recent portage version using the ebuilds. How are the backtraces in the logs related to the error message in your initial comment? Maybe this helps: http://www.gentoo.org/proj/en/portage/doc/manually-fixing-portage.xml No, it doesn't help. Anyway, I can re-emerge portage successfully. It's very strange what has happened there. Maybe I should reinstall it completely? Maybe its a permissions issue in /usr/lib64/portage/pym or a subdirectory. If you remove 'userpriv' from FEATURES then it might make the problem go away. Look in the tracebacks- note that w/in portage.ebuild.config, it's attempting a from portage.data import portage_gid... works it way down to an accessing of portage.ebuild.config.autouse; however, since portage.ebuild.config isn't fully imported yet (meaning attributes aren't there in full yet), this goes boom. It's a cyclical import; remove the cycle and you'll see what the actual complaint is. That's bug #1. Bug #2 is addressed via telling us what your PORTAGE_USERNAME and PORTAGE_GROUPNAME env vars are, and checking python -c 'import pwd;print pwd.getpwnam(the-username)' and python -c 'import grp;print grp.getgname(the-groupname)' (In reply to comment #7) The cyclical import is fixed here: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=7d2026628046cf3849fce81f58567e27788450d6 Thanks. "find /usr/lib64/portage/pym -perm -o+r | xargs chmod o+r" did the trick. However, note that files under /usr/lib64/portage/pym should be world (or at least) portage readable, so that userpriv feature works out-of-the-box. (In reply to comment #9) > Thanks. "find /usr/lib64/portage/pym -perm -o+r | xargs chmod o+r" did the > trick. I very strongly doubt this fixed it- it's a no-op; you're searching for files that have o+r, than chmod o+r them. Basically, you're chmod'ing everything that already has those perms. Only theory I can come up with is that the chmod'ing of everything somehow triggered recompilation of the bytecode, but that's... not how it should work (it's mtime based, not ctime). Oops, sorry, it was -type -o-r That is the problem of remembering the actual command Well, apart from the suggestion below I think it is fixed. For people coming here, the (correct) commands to issue, as root, are: find /usr/lib64/portage/pym -perm -o-r | xargs chmod o+r find /usr/lib64/portage/pym -type d -perm -o-x | xargs chmod o+x I'll re-open this until the fix is released, since it affects portage-2.1.8.3 which is the latest stable. I'll paste the traceback here so it's easier for people to compare: File "/usr/lib64/portage/pym/portage/proxy/objectproxy.py", line 38, in __getitem__ return object.__getattribute__(self, '_get_target')()[key] File "/usr/lib64/portage/pym/portage/__init__.py", line 568, in _get_target return _get_legacy_global(name) File "/usr/lib64/portage/pym/portage/_legacy_globals.py", line 35, in _get_legacy_global portage.db = portage.create_trees(**kwargs) File "/usr/lib64/portage/pym/portage/__init__.py", line 527, in create_trees config_incrementals=portage.const.INCREMENTALS) File "/usr/lib64/portage/pym/portage/proxy/objectproxy.py", line 31, in __call__ result = object.__getattribute__(self, '_get_target')() File "/usr/lib64/portage/pym/portage/proxy/lazyimport.py", line 105, in _get_target __import__(name) File "/usr/lib64/portage/pym/portage/package/ebuild/config.py", line 29, in <module> from portage.data import portage_gid File "/usr/lib64/portage/pym/portage/data.py", line 89, in <module> _("portage: 'portage' user or group missing.")) + "\n", noiselevel=-1) File "/usr/lib64/portage/pym/portage/proxy/objectproxy.py", line 31, in __call__ result = object.__getattribute__(self, '_get_target')() File "/usr/lib64/portage/pym/portage/proxy/lazyimport.py", line 110, in _get_target _unregister_module_proxy(name) File "/usr/lib64/portage/pym/portage/proxy/lazyimport.py", line 61, in _unregister_module_proxy object.__getattribute__(proxy, '_get_target')() File "/usr/lib64/portage/pym/portage/proxy/lazyimport.py", line 106, in _get_target target = getattr(sys.modules[name], attr_name) AttributeError: 'module' object has no attribute 'autouse' This is in 2.2_rc68, but I'll leave this bug open until it's in an unmasked version. This is fixed in 2.1.9. |