Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 884967 - [frr-gentoo] Ebuild failures occuring in global scope
Summary: [frr-gentoo] Ebuild failures occuring in global scope
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Overlays (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: f0o
URL: https://qa-reports.gentoo.org/output/...
Whiteboard:
Keywords:
Depends on:
Blocks: repository-qa-issues
  Show dependency tree
 
Reported: 2022-12-09 08:27 UTC by Thomas Bracht Laumann Jespersen
Modified: 2022-12-14 13:34 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Bracht Laumann Jespersen 2022-12-09 08:27:48 UTC
Our automated repository checks [1] have detected that the 'frr-gentoo'
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/frr-gentoo.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 f0o 2022-12-11 12:43:14 UTC
(In reply to Thomas Bracht Laumann Jespersen from comment #0)
> Our automated repository checks [1] have detected that the 'frr-gentoo'
> 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/frr-gentoo.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've deprecated old versions; the CI should be passing now, can you retrigger the CI please?
Comment 2 f0o 2022-12-12 09:56:17 UTC
> * Cache regenerated successfully

Marking as Resolved
Comment 3 Thomas Bracht Laumann Jespersen 2022-12-14 13:34:40 UTC
Thanks!