[releng] Issue #8664: Module mass-rebuild for F32 Rawhide needed
by Stephen Gallagher
sgallagh reported a new issue against the project: `releng` that you are following:
``
* Describe the issue
At the Branch point, we need to perform a mass-rebuild of modular content so that they can be rebuilt against the new base module (in this case `platform:f32`). This does not seem to have happened during the F31 Branch from Rawhide, as https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-2019082... shows only those modules whose maintainers have done a manual rebuild since the Branch.
* When do you need this? (YYYY/MM/DD)
Immediately (2019-08-21)
* When is this no longer needed or useful? (YYYY/MM/DD)
When F32 goes EOL
* If we cannot complete your request, what is the impact?
Upgrade path on Rawhide will be broken for anyone with modules enabled. (That means pretty much everyone at this point).
CC @kevin
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8664
4 years, 7 months
[releng] Issue #8702: F31 stable push requests
by Adam Williamson
adamwill reported a new issue against the project: `releng` that you are following:
``
This ticket will be used for requesting pushes of tested blocker / freeze exception fixes during F31 release freezes. See https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process and https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process . Similar to candidate compose request tickets, this ticket can be closed by releng after each push and re-opened by QA each time a new push is needed.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8702
4 years, 7 months
[releng] Issue #8684: Create F32FTBFS and F32FailsToInstall Bugzilla trackers
by Miro Hrončok
churchyard reported a new issue against the project: `releng` that you are following:
``
* Describe the issue
According to the Fails to build and Fails to install policy, we need new Buzgilla trackers for Fedora 32.
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fai...
* When do you need this?
After Fedora 31 was branched (already happened).
* When is this no longer needed or useful?
When Fedora 32 goes EOL.
* If we cannot complete your request, what is the impact?
We cannot properly track F32 install and build failures.
----
I know I can create the bugizllas myself, but last time i did, it created confusion during teh mass rebuild. So I'd prefer if releng creates them. It also looks better if the trackers are created by the releng account.
Thanks
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8684
4 years, 7 months
[releng] Issue #8468: fedora-scm-requests new repository procedure
repeatedly keeps the repo owned by the releng person
by Miro Hrončok
churchyard reported a new issue against the project: `releng` that you are following:
``
1. I've create a new repository request, where something was wrong
2. @limb processed the request, closed as invalid
3. I fixed the thing and reopened the issue
4. @limb processed the request, closed as invalid again (already exists)
5. as a result, the repo was created, but owned by @limb
This is probably broken in some script that @limb runs, it probably creates the repo, checks some constraints and assigns the repo to me. When the constraints fail, the repo exists, but is not assigned to me. I cannot provide more details, because I have no idea what happens "on the other side".
This already happened twice to me:
https://pagure.io/releng/fedora-scm-requests/issue/10716
https://pagure.io/releng/fedora-scm-requests/issue/13178
In both cases, the branch was set to epel7 and initial_commit to false, if that makes any difference.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8468
4 years, 7 months
[releng] Issue #7662: Build once,
run everywhere seems to be pretty unsupported (modularity)
by Igor Gnatenko
ignatenkobrain reported a new issue against the project: `releng` that you are following:
``
* Describe the issue
Today we've encountered issue that if your modulemd contains something like
```yaml
- buildrequires:
platform: [f29]
requires:
platform: []
```
MBS doesn't tag it properly into f28-* because it checks for buildrequires and not for requires. Which is wrong: https://pagure.io/fm-orchestrator/issue/974
However, @puiterwijk mentioned that bodhi doesn't support this either because it would pick first tag instead of creating updates for multiple ones. It seems that bodhi would need to change some core parts for this.
I'm submitting this ticket just to make sure that work is scoped and if can't be completed before F29 bodhi activation point, could be workarounded.
* When do you need this? (YYYY/MM/DD)
F29 Bodhi activation point.
* When is this no longer needed or useful? (YYYY/MM/DD)
When modularity dies.
* If we cannot complete your request, what is the impact?
One of the main use-cases for modularity doesn't work.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7662
4 years, 7 months