| Summary: | stable-bot should reject atoms with a version but without an equal/greater than/littler than sign | ||
|---|---|---|---|
| Product: | Gentoo Infrastructure | Reporter: | Jeroen Roovers (RETIRED) <jer> |
| Component: | Other | Assignee: | Michael Palimaka (kensington) <kensington> |
| Status: | RESOLVED INVALID | ||
| Severity: | normal | CC: | ago, bugzilla, leio, mgorny |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=618558 https://bugs.gentoo.org/show_bug.cgi?id=618562 |
||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Jeroen Roovers (RETIRED)
2017-05-15 19:09:17 UTC
The 'package list' contents are not reusable for any Portage configuration file I'm aware of. What's the point of changing format partially if it still will require manipulation? (it's not running on infra; assigning to the people running it, CC bugzilla for necessary bugs.g.o changes) I have the code from kensington for the stablebot and could help with reasonable improvements to it too and ask kensington to deploy them, so hence CCing myself. Now for the concrete ticket at hand. The 'package list' are not reusable for anything to portage because 'package list' is universal to all architectures, and it doesn't make sense to litter what goes into package.accept_keywords for testing with all arch information. Thus, this listing has to be processed to a per-arch list anyhow. Now I don't know what "script going around that writes atoms" is being referred to, but if https://github.com/kensington/bugbot/blob/master/getatoms.py then that outputs perfectly valid snippets that are suitable for putting in /etc/portage/package.accept_keywords of the target architecture. In the example of bug 618420, it has this in package list (note lack of equal sign): x11-libs/gtk+-3.22.15 alpha amd64 arm hppa ia64 ppc ppc64 sparc x86 dev-libs/vala-common-0.34.8 alpha amd64 arm hppa ia64 ppc ppc64 sparc x86 dev-lang/vala-0.34.8 alpha amd64 arm hppa ia64 ppc ppc64 sparc x86 x11-libs/gtkmathview-0.8.0-r3 alpha amd64 hppa ia64 ppc ppc64 sparc x86 media-libs/clutter-1.26.2 amd64 x86 ... and more amd64/x86 only, and getatoms returns this for arm: ./getatoms.py -a arm --stablereq -b 618420 # bug #618420 =dev-lang/vala-0.34.8 =dev-libs/vala-common-0.34.8 =x11-libs/gtk+-3.22.15 Which is perfectly suitable for package.accept_keywords, because: "lines without any KEYWORDS imply unstable host arch", thus allowing to emerge them for arch testing. Having a list suitable for passing straight to "emerge" command is not interesting, as one needs a package.accept_keywords first anyways to reasonably test things. Afterwards it's a simple scripted variant of something like grep -v '^#' /etc/portage/package.accept_keywords |xargs emerge -1v However thanks to this getatoms.py script also supporting multiple bugs (i.e, "all open security stablereqs for an architecture", or "all open stable requests for a given architecture that has no outstanding blocking bugs"), it can generate a longer file with multiple bugs, to handle multiple at once, and then the comments neatly serve as a list of what bugs to close as done after committing and pushing of the keywords. Internally stablebot (the part that does the sanity checking on bugzilla) has to strip out legacy leading equal sign, append '.ebuild', run ekeyword on them with appropriate arches list and then repoman in all affected package directories of an up to date git tree. A '=' serves no purpose, especially as >= and other things are not valid, thus is deprecated by stablebot, while supporting it gracefully because it can with near-zero cost. And things like >= are not valid for very good and obvious reasons, which for now I'm leaving as an exercise to the reader on why, as it's sleep time. ? WAI |
