Our automated repository checks [1] have detected that the 'klondike' 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/klondike.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
"Please fix the issue ASAP, possibly via removing unmaintained, old ebuilds." The issue is caused by you removing git-2 saying: "# Almost all consumers gone, the remaining two are last-rited. # Removal in 14 days." Which is fine but you don't (morally) get to request fixes performed ASAP when you didn't care to check about what you would broke first and gave a timely warning. After all, you could have used the same QA tools you have used to find and report this issue to find which breakage would be caused by you removing said eclass. I will fix this, eventually. Right now I have more urgent matters to tend to. Unlike in 16th December, when, a direct heads up would have been appreciated.
Proper last-rites mail was sent to gentoo-dev on 2019-12-16. Reminding overlay users on top of that last-rites is a service, not an obligation, in my eyes.
The new eclass was introduced in 2013-09. It has also been sent to mailing list review before that. That is 6.5 years ago. Deprecation has been added to repoman in 2017-06. The eclass has been last rited on 2019-12-16 and removed on 2020-01-10 (i.e. almost a month later). I would like to remind you that it's your responsibility to follow mailing list announcements. If you fail to do that, it's your fault, and only yours.
(In reply to Francisco Blas Izquierdo Riera from comment #1) > "Please fix the issue ASAP, possibly via removing unmaintained, old > ebuilds." > > The issue is caused by you removing git-2 saying: > "# Almost all consumers gone, the remaining two are last-rited. > # Removal in 14 days." > > Which is fine but you don't (morally) get to request fixes performed ASAP > when you didn't care to check about what you would broke first and gave a > timely warning. > > After all, you could have used the same QA tools you have used to find and > report this issue to find which breakage would be caused by you removing > said eclass. > > I will fix this, eventually. Right now I have more urgent matters to tend > to. Unlike in 16th December, when, a direct heads up would have been > appreciated. I'd like to echo the sentiments here. Namely, that there was ample time to port ebuilds. git-2 has been dead for ages, this was common knowledge, you have received enough warnings.
As I said, this is the first time this has been sent directly to me. And it is sent with a request to fix things "ASAP". I may have had ample time to fix things, indeed. So have you also had to request directly I fixed things before it became urgent. So stop shifting the blame! If YOUR changes break things that were working before at least be humble enough to either send a patch or accept changes MAY take time. Even more so when such changes come from unpaid volunteers.
This should be fixed for now despite git-r3 uses weird permissions and users when creating the distfiles. Thanks for the tip on how to fix this Soap.
