Our automated repository checks [1] have detected that the 'AstroFloyd' 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 or have other serious QA violations. 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/AstroFloyd.html In particular, please look for highlighted error messages. 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
Yes, last weekend was bad; hopefully this one. The ebuild hasn't been changed for a while, so the culprit probably lies elsewhere.
The QA report tells you - kernel-2.eclass dropped EAPI 6 support. So the two ebuilds mentioned just need to be bumped to either EAPI 7 or 8, I think.
Fixed in commit #c48230e. @Thomas: You were right; just changing the EAPI number sufficed. Sometimes, however, when you do this, repoman will complain that the ebuild doesn't meet the requirements of the new EAPI, and so you have to go and figure out how to do the same thing now and rewrite parts of your ebuild. It can then take an hour or more to end up where you started: and ebuild that emerges that package. I love Gentoo, and I'll never want a flavour where I cannot add my own packages, but one of the few things that annoy me is that you sometimes have to stick energy into staying where you already were. Anyway, I was a bit grumpy about that, and I apologise for that, because that isn't your fault either ;-).
(In reply to AstroFloyd from comment #4) > Fixed in commit #c48230e. > > @Thomas: You were right; just changing the EAPI number sufficed. Sometimes, > however, when you do this, repoman will complain that the ebuild doesn't > meet the requirements of the new EAPI, and so you have to go and figure out > how to do the same thing now and rewrite parts of your ebuild. It can then > take an hour or more to end up where you started: and ebuild that emerges > that package. I love Gentoo, and I'll never want a flavour where I cannot > add my own packages, but one of the few things that annoy me is that you > sometimes have to stick energy into staying where you already were. Anyway, > I was a bit grumpy about that, and I apologise for that, because that isn't > your fault either ;-). Thanks! I didn't read your comments as grumpy, but I appreciate the consideration :-)
