Bug 709120 – [klondike] Ebuild failures occuring in global scope

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description Michał Górny 2020-02-10 22:09:10 UTC]

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

[Comment 1 Francisco Blas Izquierdo Riera (RETIRED) 2020-02-16 18:37:42 UTC]

"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.

[Comment 2 Andreas Sturmlechner 2020-02-16 19:33:55 UTC]

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.

[Comment 3 Michał Górny 2020-02-16 19:40:21 UTC]

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.

[Comment 4 David Seifert 2020-02-16 19:52:30 UTC]

(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.

[Comment 5 Francisco Blas Izquierdo Riera (RETIRED) 2020-02-16 20:32:03 UTC]

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.

[Comment 6 Francisco Blas Izquierdo Riera (RETIRED) 2020-02-16 21:32:29 UTC]

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.