[releng] Issue #7017: Set up koji policy/channels for known archful noarch
packages.
by Ralph Bean
ralph reported a new issue against the project: `releng` that you are following:
``
Reported by @sgallagh in a discussion with @ralph and @mikeb.
There are these funny things called 'archful noarch' packages. Packages which produce noarch binary rpms, but which can only be built on specific architectures (x86_64, specifically).
In the traditional world, when you submit a build of one of these package to koji, your build is sent to a builder with a random architecture. Usually this is wrong, and your build fails. You then submit and submit again until it works. This is colloquially called "winning the builder lottery." It is annoying, but people put up with it.
In the modular world, this poses a real problem. The MBS won't know *why* the build failed and we can't expect it to try over and over again until it wins the builder lottery. We need a better solution.
The solution we came up with on a whiteboard (a few months ago) was that we can set up a *channel* in koji called `x86_64-builders` (or something like that). Then, start maintaining a list of all known "archful noarch" packages. This could start with one or two packages and then we grow it over time.
We would then create a new koji hub policy that says something like:
"Whenever a build is submitted of a package that matches any of the packages in the curated list, submit the build to the x86_64-builders channel."
What do you think? Will it work?
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7017
5 years, 5 months
[releng] Issue #7012: Tag hierarchy for modular updates.
by Ralph Bean
ralph reported a new issue against the project: `releng` that you are following:
``
OK, the patch to bodhi that enables mashing modules is basically done. @mcurlej is wrapping up the test suite. Our target is to merge, release, and deploy it around Sept 20th, just after Beta freeze thaws.
In order to use it, we're going to need to create some new tags for the tag hierarchy.
The tag hierarchy for f27 currently looks like:
~❯ koji list-tag-inheritance --reverse f27
f27 (417)
├─f27-binutils-rebuild (1868)
├─f27-rebuild (1849)
├─f27-gcc-abi-rebuild (1274)
├─f27-atomic (433)
├─f27-openh264 (432)
├─f27-modularity (431)
├─f27-compose (419)
└─f27-updates (418)
├─f27-pending (427)
├─f27-override (424)
│ └─f27-build (425)
│ ├─f27-gnome (2116)
│ ├─f27-ocaml2 (1838)
│ ├─f27-boost (1805)
│ ├─f27-perl (1489)
│ ├─f27-ocaml (1082)
│ ├─f27-llvm4 (493)
│ └─f27-infra (428)
│ └─f27-infra-stg (429)
│ └─f27-infra-candidate (430)
├─f27-updates-pending (423)
├─f27-updates-testing (421)
│ └─f27-updates-testing-pending (422)
│ └─f27-signing-pending (426)
└─f27-updates-candidate (420)
For f27 updates, we're going to need a tag structure something like this:
~❯ koji list-tag-inheritance --reverse f27-modular
f27-modular
└─f27-modular-updates
├─f27-modular-pending
├─f27-modular-updates-pending
├─f27-modular-updates-testing
│ └─f27-modular-updates-testing-pending
│ └─f27-modular-signing-pending
└─f27-modular-updates-candidate
Once that's done (and once the updated bodhi is deployed) we'll need to create a 'F27 Modular' "release" in bodhi's database that points to these tags.
Lastly, the MBS will need to start tagging its built modules into `f27-modular-updates-candidate`.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7012
5 years, 6 months