rel-eng November 2017

rel-eng@lists.fedoraproject.org

12 participants
202 discussions

[pungi-fedora] PR #438: Add post-compose rsync script
by Kellin 08 Mar '21

08 Mar '21

kellin opened a new pull-request against the project: `pungi-fedora` that you are following: `` Add post-compose rsync script `` To reply, visit the link below or just reply to this email https://pagure.io/pungi-fedora/pull-request/438

3 2

[pungi-fedora] Issue #426: Convert file sync from one-liner to durable shell script
by Kellin 15 May '20

15 May '20

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

4 7

[pungi-fedora] PR #433: Make release-candidate.sh script more durable
by Kellin 13 Apr '19

13 Apr '19

kellin opened a new pull-request against the project: `pungi-fedora` that you are following: `` Make release-candidate.sh script more durable `` To reply, visit the link below or just reply to this email https://pagure.io/pungi-fedora/pull-request/433

3 2

[releng] PR #7119: A SOP for adjusting EOLs on arbitrary branches.
by Ralph Bean 13 Apr '19

13 Apr '19

ralph opened a new pull-request against the project: `releng` that you are following: `` A SOP for adjusting EOLs on arbitrary branches. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/pull-request/7119

4 3

[pungi-fedora] PR #381: AH: Stop generating raw-xz images
by Colin Walters 13 Apr '19

13 Apr '19

walters opened a new pull-request against the project: `pungi-fedora` that you are following: `` AH: Stop generating raw-xz images `` To reply, visit the link below or just reply to this email https://pagure.io/pungi-fedora/pull-request/381

7 10

[releng] Issue #7174: Proposal: Give Bodhi a REST API for mashing
by Randy Barlow 12 Apr '19

12 Apr '19

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

3 3

[releng] Issue #7150: Retiring ghostscript-fonts for F27 without noticing it is already Final Freeze
by Zdenek Dohnal 12 Apr '19

12 Apr '19

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

3 6

[releng] Issue #7104: Koji tries to build i686-only packages on i386 (error: Architecture is not included: i386)
by Igor Gnatenko 12 Apr '19

12 Apr '19

ignatenkobrain reported a new issue against the project: `releng` that you are following: `` In rust-packaging we have ``` BuildArch: noarch ExclusiveArch: %{rust_arches} noarch ``` Where ``` [brain@ignatenko-w541 rust-packaging]$ rpm --eval %rust_arches x86_64 i686 armv7hl aarch64 ppc64 ppc64le s390x ``` Somehow koji schedules build on machine which has i386 architecture: https://koji.fedoraproject.org/koji/taskinfo?taskID=22585560 `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7104

4 11

[releng] Issue #7097: Automate the process of reviewing and merging PRs on releng/fedora-scm-requests
by Pierre-YvesChibon 12 Apr '19

12 Apr '19

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

3 6

[releng] Issue #7083: orphan-all-packages.py should remove bugzilla_contact entries from fedora-scm-requests as well
by Till Maas 12 Apr '19

12 Apr '19

till reported a new issue against the project: `releng` that you are following: `` orphan-all-packages.py only updates pagure, but fedora-scm-requests also contains owners for other branches such as EPEL. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7083

3 4

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

rel-eng November 2017