Our automated repository checks [1] have detected that the 'srcshelton' 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/srcshelton.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. Please note that due to technical limitations of pkgcore, the processing stops on the first error found. Once solved, please wait ~30 minutes for the report to refresh in case new errors may appear. 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.
Yeah, I have a problem here - the identified issues are all fixed, but I've been away for a while. In the meantime, GLEP 0076 was passed, *requiring* a 'Signed-off-by' entry in each commit message. (Which makes sense for main-repo commits... but this is a small overlay where all of the commits are authored by myself, and so it's certainly arguable that this is redundant...) ... but the issue is that I only found out about this when I tried to push an update to resolve this issue. Which means that I have some 250+ commits which are being rejected due to lacking the now-required entry. I've updated by scripts to add this to *new* commits - but the problem I face is that (i) I'm not sure of any automated way to add the extra line to the affected commits, and (ii) this would require a major re-write of the history of the repo, breaking it for anyone (... let's face it: all of my hosts in reality) which are using the primary GitHub mirror. So this may not be fixable: I may have to request that the Gentoo-hosted overlay repo be retired, although this seems a shame. Is there at least a good solution to point (i) above - a way to automatically add an additional line to many commits without human involvement (I realise that an interactive rebase will allow commit messages to be edited, but I believe that this is only interactive). Any suggestions?
git rebase -i --signoff origin/master Then use 'r' on the first commit to edit its commit message, and save it. Git should rewrite all the commits afterwards.
Ping².
Apologies - life has intervened, as it has a tendency to do. I *am* planning to fix as soon as I get a chance, though... this may be a few weeks yet, I'm afraid.
The bug seems to be fixed in the repository. Closing.
