Noticed today when tried to keyword ebuild from prefix system: $ ekeyword ~ia64 dev-haskell/shelly/shelly-1.6.8.1.ebuild Traceback (most recent call last): File "/home/siarheit/gentoo/rap/usr/lib/python-exec/python3.5/ekeyword", line 41, in <module> ekeyword.main(sys.argv[1:]) File "/home/siarheit/gentoo/rap/usr/lib64/python3.5/site-packages/gentoolkit/ekeyword/ekeyword.py", line 528, in main if not portage_settings().get('NOCOLOR', 'false').lower() in ('no', 'false'): File "/home/siarheit/gentoo/rap/usr/lib64/python3.5/site-packages/gentoolkit/ekeyword/ekeyword.py", line 347, in portage_settings return portage.db['/']['vartree'].settings File "/home/siarheit/gentoo/rap/usr/lib64/python3.5/site-packages/portage/proxy/objectproxy.py", line 44, in __getitem__ return object.__getattribute__(self, '_get_target')()[key] KeyError: '/' $ portageq envvar EROOT /home/siarheit/gentoo/rap/ I've worked it around locally as [1] but not sure if it's ok or 'portage.root' should be used instead of 'portage.settings['EROOT']'. [1]: workaround --- a/pym/gentoolkit/ekeyword/ekeyword.py +++ b/pym/gentoolkit/ekeyword/ekeyword.py @@ -344,7 +344,8 @@ def portage_settings(): """Return the portage settings we care about.""" # Portage creates the db member on the fly which confuses the linter. # pylint: disable=no-member - return portage.db['/']['vartree'].settings + eroot = portage.settings['EROOT'] + return portage.db[eroot]['vartree'].settings def load_profile_data(portdir=None, repo='gentoo'):
ekeyword works for me in Prefix, I think this is fixed nowadays
