Our automated repository checks [1] have detected that the 'mysql' 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: http://gentoo.github.io/repo-qa-check-results/mysql.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
Your script is flawed if it cannot find these inherits. Works fine in portage
No, they're not. inherit java-pkg-2 java-ant-2 "${VCS_INHERIT}" This evaluates to inherit "" (".eclass") when VCS_INHERIT is unset. Portage bugs (like lack of quoting in random places) don't justify broken ebuilds.
Tell me how this is not broken: !!! mariadb-java-client-9999.ebuild, line 23: Called inherit 'java-pkg-2' 'java-ant-2' 'eutils' 'git-r3' !!! ebuild-default-functions.lib, line 230: Called __internal_inherit 'java-pkg-2' !!! ebuild-daemon.lib, line 37: Called die !!! The die message: [FATAL] !!! unknown inherit command from pythonic side, 'gen_metadata 256' for eclass java-pkg-2
(In reply to Michał Górny from comment #2) > No, they're not. > > inherit java-pkg-2 java-ant-2 "${VCS_INHERIT}" > > This evaluates to inherit "" (".eclass") when VCS_INHERIT is unset. Portage > bugs (like lack of quoting in random places) don't justify broken ebuilds. So you would rather have 2 inherit commands which, as I understand it, is another QA no-no?
(In reply to Brian Evans from comment #4) > (In reply to Michał Górny from comment #2) > > No, they're not. > > > > inherit java-pkg-2 java-ant-2 "${VCS_INHERIT}" > > > > This evaluates to inherit "" (".eclass") when VCS_INHERIT is unset. Portage > > bugs (like lack of quoting in random places) don't justify broken ebuilds. > > So you would rather have 2 inherit commands which, as I understand it, is > another QA no-no? There are numerous possibilities of solving this particular issue which require only a small amount of good will. Those include: 1. 2 inherit commands -- which are actually fine for non-ancient Package Managers, 2. non-quoted ${VCS_INHERIT} variable (which causes empty value not to be treated as parameter), 3. VCS_INHERIT as an array -- then "${VCS_INHERIT[@]}" could expand to zero parameters, 4. removing the live code from release ebuild :P. I guess I could find one or two more solutions if I tried hard but I guess that's not the point.
Quotes removed from VCS_INHERITS and mysql-connector-python dropped as it is in the tree with a newer version.
