[releng] Issue #7113: proposal to run bodhi updates pungi composes with
`--no-label`
by Dusty Mabe
dustymabe reported a new issue against the project: `releng` that you are following:
``
We have just started running bodhi updates via pungi (woo!!). One of the reasons the Atomic team has been helping drive this initiative is so that we can get better versioning of our ostrees output by fedora (via pungi).
When we started doing the runs we added a label to them of the form: `Update-20171025.1312`. Which translates into an ostree version of `27_Update.20171025.1312`. The atomic working group had previously got together and [decided](https://pagure.io/atomic-wg/issue/229) that a versioning scheme like `27.2017025.0` would be what we went with for better versioning for ostrees. This scheme was discussed with releng (including dennis) and also added as an RFE to pungi, which was implemented by @lsedlar in [PR](https://pagure.io/pungi/pull-request/592).
With the updates run we can get the desired version if we provide `--no-label` to pungi instead of actually giving it a label. This warrants the question: "what is the value of the label for an updates run?". Do we need it? What is it used for?
If we don't need it then I'd love to just use `--no-label`. If we do need it then we'll have to implement another smart versioning macro for ostrees in pungi.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7113
5 years, 5 months
[releng] Issue #7074: Compose configuration changes needed for modular fedora
by Dennis Gilmore
ausil reported a new issue against the project: `releng` that you are following:
``
* enable createiso generation on all arches.
* enable Minimal and Base container everywhere it makes sense
* Enable disk images (raw.xz and qcow2) as appropriate, x86_64, ppc64le, aarch64
* configure 32 bit arm images using apliance-creator
* configure syncing of contanet to mirrors
* configure sending of compose reports to email lists
* ensure all needed fedmsg's are sent
* setup empty repos for updates and updates-testing for fedora 27
@rashmin and @tmlcoch I will setup a meeting to go over the steps needed and how to test and get it implemented. With this done we should be able to setup compose configurations for Beta.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7074
5 years, 5 months
[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