[pungi-fedora] Issue #426: Convert file sync from one-liner to durable shell
script
by Kellin
kellin reported a new issue against the project: `pungi-fedora` that you are following:
``
The way we rsync composes today is a one-liner bash script that is not very durable and requires that a release engineer babysit it through the entire four hour rsync process.
I am going to make this more durable, however, it will also slightly change our process behind the scenes.
Today if a process works or is DOOMED after a full run it is assigned an RC release number. (EG: 1.1, 1.2, 1.3, etc). If the compose fails quickly from something such as a failure to have signed packages then it will not be assigned a release candidate.
Per @mohanboddu there is not a durable way to identify the all of the different ways the special case DOOMed composes occur so they will be assigned an RC number after the automation is deployed.
The only visible change will be extra gaps in the RC composes in /pub/alt/stage that represent these extra numbers being inserted to the sequence.
@mohanboddu is fine with this change; does anyone else have objections?
@ausil , @kevin , @puiterwijk please let me know. The initial script PR will be coming within the next two business days.
``
To reply, visit the link below or just reply to this email
https://pagure.io/pungi-fedora/issue/426
3 years, 11 months
[releng] Issue #7174: Proposal: Give Bodhi a REST API for mashing
by Randy Barlow
bowlofeggs reported a new issue against the project: `releng` that you are following:
``
Greetings releng!
@puiterwijk and I came up with a glorious plan for Bodhi to give it a REST API to control mashing. This is needed in order to automate mass container rebuilds because Bodhi will need to be able to mash the lower layers into the registry before the higher layers that depend on them can be built. A REST API will allow automated services to ask Bodhi to do that when needed.
Giving Bodhi a REST API into the masher opens the possibility for a lot of other Nice Things™ for releng, such as a much better way to see the status of the masher than we have today. Aren't you tired of tailing the logs to see what the masher is doing, or looking for lock files in the mash directory? Wouldn't it be nice if a CLI or possibly even web interface could tell you what's up? This will even make it possible to give bodhi a web interface to control the masher.
Anyways, I'd like to solicit releng's feedback on the proposal. I have created a project for this that has all of the individual tickets that express the proposal in more detail than I've written here:
https://github.com/fedora-infra/bodhi/projects/2
The tickets are arranged from top to bottom in priority order. The tickets that are marked "high priority" mean that I am going to attempt to get them done by Feb 20 (no guarantees though!), and they are required for Bodhi to support containers. The remaining tickets I will pursue after that. Please peruse the various tickets, and please provide feedback in the tickets if you have any.
I filed this ticket so we could discuss it during one of your weekly meetings, if you like.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7174
5 years
[releng] Issue #7150: Retiring ghostscript-fonts for F27 without noticing it
is already Final Freeze
by Zdenek Dohnal
zdohnal reported a new issue against the project: `releng` that you are following:
``
Hi,
this Monday I finally got to issue which I already discussed on devel-list - removing ghostscript-fonts from Fedora, because they are deprecated long ago and they are replaced by urw-base35-fonts. Two remaining components ghostscript and hylafax+, which had dependency on ghostscript-fonts, removed this dependency, so I retired it for F27 and F28.
But problem is, I didn't check Fedora 27 schedule, and F27 is already in Final Freeze, in which retiring packages mustn't happen (I check emails regulary on devel, devel-announce, fedora-announce and test-announce, but all I saw was postponing Fedora 27, so I thought it isn't Final Freeze already), I'm really sorry about it.
What can I do now for F27? Should I request unretirement for only one release? Or will package be retired for F27?
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7150
5 years
[releng] Issue #7097: Automate the process of reviewing and merging PRs on
releng/fedora-scm-requests
by Pierre-YvesChibon
pingou reported a new issue against the project: `releng` that you are following:
``
The https://pagure.io/releng/fedora-scm-requests/ project is used for few things:
- Ask for a new package to be added to the distro
- Ask for a new branch on an existing package
- Tune the anitya integration flag
- Set bugzilla overrides (so EPEL bugs go to a different person than the Fedora ones)
The first two tasks are requested by tickets at: https://pagure.io/releng/fedora-scm-requests/issues and processed by releng using [fedrepo-req]().
The last two tasks are requested by PRs and could be automatically reviewed and merged.
I would like to propose that we do this automation, all it requires is checking that the person opening the ticket has ACLs on the project (up to us if we want to limit this to ``admins`` for example). If these people have ACL on the project, then it's just like on pkgdb before, we let the users configure things the way they want.
I do not think there is a good reason to be blocking any changes the maintainers want to do on their package.
Thoughts?
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7097
5 years