Our automated repository checks [1] have detected that the 'luke-jr' 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/luke-jr.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
Dropped old xpra and imported 'user' eclass for now.
Reopening, there are some new failures reported.
ping
These new "issues" are huge breakage caused by eclass changes. I am not able to address them immediately. If you have any suggestions, I can see if there's a way to merge them... (I've stopped using the more reliable Py2-based Xpra, so maybe I can just drop its dependencies)
No rush to fix them on my part, just good to know that you're aware of the issue. I'll leave it open for now. If you want, we can also remove the overlay from the list and add it back later?
(In reply to Thomas Bracht Laumann Jespersen from comment #5) > If you want, we can also remove the overlay from the list and add it back > later? Would would be the benefit of this?
(In reply to Luke-Jr from comment #6) > (In reply to Thomas Bracht Laumann Jespersen from comment #5) > > If you want, we can also remove the overlay from the list and add it back > > later? > > Would would be the benefit of this? You wouldn't be pinged about it :-)
I believe I've addressed all the issues here (mostly by dropping old stuff I probably no longer need)
(In reply to Luke-Jr from comment #8) > I believe I've addressed all the issues here (mostly by dropping old stuff I > probably no longer need) Thanks! I just ran another overlay QA scan and it flagged this overlay as having some issues, so I'm reopening this bug.
