Our automated repository checks [1] have detected that the 'improvise' 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/improvise.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
These ebuilds are from tinkering in days of mentoree with tampakarap in kde. They've been there mostly for years, mostly forgotten, and caused no complaint until you thrust automated repository checks onto them. Have you nothing better to do?? I shall attempt a purge of these old ones but if I miss some and you wish to carry out your threat of purging the overlay, knock yourself out. I use it only locally to work new ebuilds which I can just as easily go in the main git tree anyway. Just get off the back.
The cat x11-misc/ I believe I deleted already Aug 10 in a mass purge yet you made this bug 2015-08-15 08:04 UTC. Please explain that. It looks like a huge pause in between. ditto the cat kde-misc/ && media-libs/. The more I look the more it seems you made an invalid bug
(In reply to Ian Delaney from comment #1) > These ebuilds are from tinkering in days of mentoree with tampakarap in kde. > They've been there mostly for years, mostly forgotten, and caused no > complaint until you thrust automated repository checks onto them. > > Have you nothing better to do?? Your response is very inappropriate and unnecessarily offensive. The checks are run on all public Gentoo repositories in order to help their owners keep working ebuilds in there, and save random users from reporting those issues one by one when they see them. So far, repository owners are rather grateful for bug reports. And if you really care, yes, I have many better things to do than waste my time for Gentoo which so far has one of the most ungrateful communities I've ever seen. If you wish me to retire, please state so openly. However, I'm afraid I've wasted too much on joining to just retire like that because of some self-centered developer who has no manners and replies to bug reports with aggression. (In reply to Ian Delaney from comment #2) > The cat x11-misc/ I believe I deleted already Aug 10 in a mass purge yet you > made this bug 2015-08-15 08:04 UTC. Please explain that. It looks like a > huge pause in between. > ditto the cat kde-misc/ && media-libs/. > The more I look the more it seems you made an invalid bug https://gitweb.gentoo.org/user/improvise.git/ There are no new pushes since November 2014.
Michał and Ian, please try to resolve this between yourselves or try to get someone to mediate this issue for you. Calling ComRel to resolve this sort of dispute is "non-productive".
@Ian, from my point of view, if that overlay is not really being used/maintained anymore, it should be removed to prevent users from trying to use it and get some bugs/issues with them. And I don't see anything offensive on running automated tests to try to clean the offered overlays and improve a bit their quality :/ (I personally appreciate that effort as it's "common" to hit really ugly ebuilds in some overlays :( ) If you still want to use that overlay "privately" I guess it shouldn't be a problem to keep the overlay untouched but not to "offer" it to our users :/
ok let's review the scene here. Doing qa runs on repos is fine in principle. The reality is that the capacity or ability to do automated repository checks is new, your innovation to my understanding. So the notion of cleaning this overlay of mine to come up 'green' is fine. However I have no idea what's going on with it. So let's get to the technical aspects of this. The reports in the link of URL persistently list x11-misc/, kde-misc/ (2 packages) & media-libs/. See Comment 2. So after purging a package, here is what the little overlay has. ~/github/improvise $ ls README app-admin app-emulation dev-python metadata profiles sets sets.conf repoman full yields some harmless warnings. So I already asked you in Comment 2 to explain it, but you seem to have skipped over that part. These categories and the packages have long been purged. They do not exist in my overlay. How you are getting runs on discarded broken ebuilds I do not know. The less said about your indignant comments the better, Let's settle for no I don't wish you to resign and leave gentoo. Your contribution in the technical aspect is valid and worthy. So I won't say what isn't. I have equal claim to not have to leave having invested much into gentoo, but clearly far less than yours in total 'volume' and scope. I had not checked this bug for over 2 weeks and was hoping it was just closed invalid. If there is something I need invoke at my end by all means outline it but I have no idea. The culprit ebuilds appear long deleted. I have no clue as to how the CI checks work. I am more than content to leave that to you. I'd prefer to have the overlay remain but I don't critically need it. "not to "offer" it to our users is fine. It was never intended for use by users. It's an overlay so it could otherwise be, but it isn't. The notion of categorising overlay for offer to users or not is another admin burden which I am sure no-one wants to have to create. It's not that I see anything offensive on running automated tests on the overlay. That is an interpretation. In practice, it's being treated with same diligence as the portage tree itself. Until the making of CI, it was silent and ignored.
The bug seems to be fixed in the repository. Closing.
