For reasons, I have a `unifi` repo which maintains python2.7 packages and mongodb-4.0 for compatibility with Ubiquiti's Network Controller. This repo is generally disabled with a `*/*::unifi` entry in /etc/portage/package.mask. This is likely a very niche setup, but running `eclean` with `--changed-deps` results in these masked packages being sourced which causes a crash/stack-trace. ``` $ sudo eclean -p packages --changed-deps * Building file list for packages cleaning... * ERROR: dev-libs/snowball-stemmer-0.20140325::unifi failed (depend phase): * multilib: EAPI 5 not supported * * Call stack: * ebuild.sh, line 628: Called source '/var/db/repo/unifi/dev-libs/snowball-stemmer/snowball-stemmer-0.20140325.ebuild' * snowball-stemmer-0.20140325.ebuild, line 6: Called inherit 'epatch' 'toolchain-funcs' 'versionator' * ebuild.sh, line 308: Called __qa_source '/var/db/repo/unifi/eclass/toolchain-funcs.eclass' * ebuild.sh, line 123: Called source '/var/db/repo/unifi/eclass/toolchain-funcs.eclass' * toolchain-funcs.eclass, line 25: Called inherit 'multilib' * ebuild.sh, line 308: Called __qa_source '/var/db/repo/srcshelton/eclass/multilib.eclass' * ebuild.sh, line 123: Called source '/var/db/repo/srcshelton/eclass/multilib.eclass' * multilib.eclass, line 14: Called die * The specific snippet of code: * *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;; * * If you need support, post the output of `emerge --info '=dev-libs/snowball-stemmer-0.20140325::unifi'`, * the complete build log and the output of `emerge -pqv '=dev-libs/snowball-stemmer-0.20140325::unifi'`. * Working directory: '/usr/lib/python3.11/site-packages' * S: '/storage/system/var/tmp/portage/dev-libs/snowball-stemmer-0.20140325/work/snowball-stemmer-0.20140325' Traceback (most recent call last): File "/usr/lib/python-exec/python3.11/eclean", line 41, in <module> main() File "/usr/lib/python3.11/site-packages/gentoolkit/eclean/cli.py", line 679, in main doAction(action, options, exclude=exclude, output=output) File "/usr/lib/python3.11/site-packages/gentoolkit/eclean/cli.py", line 530, in doAction clean_me = findPackages( ^^^^^^^^^^^^^ File "/usr/lib/python3.11/site-packages/gentoolkit/eclean/search.py", line 613, in findPackages ebuild_metadata = dict(zip(keys, port_dbapi.aux_get(cpv, keys))) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3.11/site-packages/portage/dbapi/porttree.py", line 655, in aux_get return loop.run_until_complete( ^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3.11/asyncio/base_events.py", line 653, in run_until_complete return future.result() ^^^^^^^^^^^^^^^ portage.exception.PortageKeyError: 'dev-libs/snowball-stemmer-0.20140325' ``` Perhaps `eclean` should either itself adhere to (and skip) package.mask entries, or should silently skip packages for which evaluation fails (without stopping/crashing)?
package.mask doesn't help if an ebuild is unsourcable because it occurs at a different layer from metadata generation. But it's a fair point that eclean should try swallow such errors / not abort.
(In reply to Sam James from comment #1) > package.mask doesn't help if an ebuild is unsourcable because it occurs at a > different layer from metadata generation. > > But it's a fair point that eclean should try swallow such errors / not abort. FWIW, Portage itself does exactly that in the definition of ChangedDepsSet at https://github.com/gentoo/portage/blob/4ceb199aab8035fdf2ebd244e213ca63c29b4d5f/lib/portage/_sets/dbapi.py#L621.
