Our automated repository checks [1] have detected that the 'dev1990-overlay' 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/dev1990-overlay.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
I think I messed up metadata.xml enclosures. This commit https://github.com/dev-0x7C6/dev1990-overlay/commit/049d1dec9a9e888957148043b6e9293dc080f98c should fix this problem. Is there any CI integration framework that I can add to my repository to avoid this kind of situations? I'm also interested in raising quality of my overlay so any advice will be welcome.
(In reply to Bartłomiej Burdukiewicz from comment #1) > Is there any CI integration framework that I can add to my repository to > avoid this kind of situations? I'm also interested in raising quality of my > overlay so any advice will be welcome. You can use app-portage/repoman (very slow, limited) in a git pre-push hook, or dev-util/pkgcheck manually. There's also dev-util/shellcheck{,-bin} which catches a lot of syntax errors neither of those do, but it needs to be told to ignore some things as it's meant for self-contained shell scripts, not ebuilds.
I guess I could look into providing a minimal Docker container for testing overlays.
(In reply to Michał Górny from comment #3) > I guess I could look into providing a minimal Docker container for testing > overlays. If you're interested in that, my attempt is at: https://hub.docker.com/repository/docker/mgorny/gentoo-overlay-ci The initial build attempt is still in progress. Once it builds sucessfully, I think you can get it via: docker pull mgorny/gentoo-overlay-ci docker run -e REPO=dev1990-overlay mgorny/gentoo-overlay-ci
The bug seems to be fixed in the repository. Closing.
(In reply to Anthony Parsons from comment #2) > You can use app-portage/repoman (very slow, limited) in a git pre-push hook, > or dev-util/pkgcheck manually. > > There's also dev-util/shellcheck{,-bin} which catches a lot of syntax errors > neither of those do, but it needs to be told to ignore some things as it's > meant for self-contained shell scripts, not ebuilds. Thanks for tips. (In reply to Michał Górny from comment #4) > (In reply to Michał Górny from comment #3) > > I guess I could look into providing a minimal Docker container for testing > > overlays. > > If you're interested in that, my attempt is at: > > https://hub.docker.com/repository/docker/mgorny/gentoo-overlay-ci > > The initial build attempt is still in progress. Once it builds sucessfully, > I think you can get it via: > > docker pull mgorny/gentoo-overlay-ci > docker run -e REPO=dev1990-overlay mgorny/gentoo-overlay-ci Thank you, I'll try to integrate it with gitlab ci.
