Our automated repository checks [1] have detected that the 'raw' 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/raw.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
sys-cluster/kerrighed-9999-r1 removed from this place. Sorry for long time waiting, just skipped...
A lot of new failures at the same URL. Some of them look pretty dangerous too. Please consider this urgent.
Ping. Could you handle the remaining issues, please?
I see next problems - pathes: I use "overloading" of core eclass with same names: source "${PORTDIR}/eclass/kernel-2.eclass" source "${PORTDIR}/eclass/mozcoreconf-2.eclass" I am ready to do revision for mozcoreconf-2.eclass, as now I prefer mainstream mozillaz (just no time to), but my kernel-2.eclass is most useful feature and I don't know now how to make eclass (same name) overloading, keeping robots happy. I can change "${PORTDIR}" to "${PORTDIR:-$ROOT/usr/portage}", but are your robot have portage here? Also it calling perl script (Kconfig.pl) from installed packages from "depend" state - I solved (testing) it now. But previous problem I'm not ready to fix (now). But failures in overloading happened only becouse I use this eclasses inside overlay. I also can remove this ebuild ;), as both packages unmaintained long time... What you suggest?
OK, hiding sys-kernel/kerrighed-sources && www-client/* into "unmaintained". Now robot must be happy. But to future better to legalize eclass overloading in overlay in some form.
Eclass overriding is supported and works well. You just put them in your overlay, and inherit them like normal Gentoo eclasses.
Hmm... [Main|up]stream kernel-2.eclass copy to overlay and rename to kernel-2-gentoo.eclass, then make own kernel-2.eclass with inherit kernel-2-gentoo.eclass ?
... and replace all kernel-2_ to kernel-2-gentoo_
Wouldn't it be simpler to name your eclass kernel-2-raw or like that, and use it in your ebuilds? Then you wouldn't have to modify the Gentoo thingie.
I use my kernel-2.eclass with your ebuilds. I just build & install vanilla-sources & gentoo-sources automated on emerge on all my machines. I don't know nothing about somebody else who use it, but anymore.
Then it's not supported. You can't apply eclasses the reverse way -- you have to have your own ebuilds as well.
repos.conf eclass-overrides is for secret sins?
(In reply to Denis Kaganovich from comment #12) > repos.conf eclass-overrides is for secret sins? Yes. I think even the manual says it's dangerous and breaks some stuff. Furthermore, it's not possible to expose it via overlay unless user modifies configuration for Gentoo.
OK. Better to communicate with robots :)
PS Looks like fixed last robot's issues in last commit. Will check.
The bug seems to be fixed in the repository. Closing.
