Our automated repository checks [1] have detected that the 'salfter' repository contains ebuilds that trigger fatal errors during the cache regeneration. This usually means that the ebuilds call 'die' in global scope indicating serious issues. Global-scope failures prevent the ebuild not only from being installed but also from being properly processed by the Package Manager. Since metadata can not be obtained for those ebuilds, no cache entries are created for them and the Package Manager needs to retry running them every time it stumbles upon them. This involves both a serious slowdown and repeating error output while performing dependency resolution. The most common cause of global-scope failures is use of removed or banned APIs in old ebuilds. In particular, this includes eclasses being removed or removing support for old EAPIs. Nonetheless there are also other issues such as performing illegal operations in global scope (external program calls), malformed bash in ebuilds or malformed metadata.xml. The error log for the repository can be found at: https://qa-reports.gentoo.org/output/repos/salfter.html In particular, please look for highlighted '!!! ERROR' and '!!! caught exception' lines. The former usually mean failures coming from eclasses and the ebuild itself, while exceptions usually mean malformed ebuilds or metadata.xml. While at it, please consider fixing global-scope 'use' call warnings (if any). They are not fatal but are considered a serious QA violation. 'use' functions must not ever be called outside of phase functions. Please fix the issue ASAP, possibly via removing unmaintained, old ebuilds. We reserve the right to remove the repository from our list if we do not receive any reply within 4 weeks. [1]:https://wiki.gentoo.org/wiki/Project:Repository_mirror_and_CI
Ping.
Didn't see this until a couple of days ago...it's now fixed in commit 9d21dfc.
There are still more issues to fix, please see the URL. The report is refreshed every 20 minutes, and it might not catch some issues until you fix previous ones.
The remaining issues should now be resolved.
Still more. Look for all ebuilds inheriting python or distutils.
Final ping.
There's nothing using the old distutils anymore: find /var/lib/layman/salfter -name \*.ebuild -exec grep -Hi inherit \{} \; | grep distutils | grep -v r1 returns nothing. There was one package (media-sound/pykaraoke-0.7.5), and it's been updated. The only ebuild that inherits any Python-related ebuilds at this point is net-nntp/sickrage-9999, which hasn't triggered any problems previously. What tool are you using for these checks? The attached logfile indicates something called "pmaint," which appears to be part of sys-apps/pkgcore. I tried installing it, but wasn't able to get it to do anything useful. It appears to install no configuration files, the error messages from it are less than informative, and the documentation at https://wiki.gentoo.org/wiki/Pkgcore is as clear as mud.
Yes, it's pkgcore with a few local patches (nothing that would influence this though). You don't need any specific config, it just groks Portage's config files fine for me. Then it's 'pmaint regen <repository-name>'. However, you can just use 'egencache' from Portage. I'm just PkgCore because it's faster, and speed is important when I have to run it for all the repositories. FWICS, the repo is good now. I'll close the bug via the automatic script.
The bug seems to be fixed in the repository. Closing.