rel-eng January 2019

rel-eng@lists.fedoraproject.org

10 participants
236 discussions

[releng] Issue #7201: Initial discussion for rpm-ostree jigdo ♲📦
by Colin Walters 12 Apr '19

12 Apr '19

walters reported a new issue against the project: `releng` that you are following: `` See https://github.com/projectatomic/rpm-ostree/issues/1081 and https://lists.fedoraproject.org/archives/list/rel-eng@lists.fedoraproject.o… Goal here is to determine initial design of integration; the whole idea is to decrease the burden on releng so hopefully we succeed at that! `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7201

5 6

[releng] Issue #7195: ODCS: create Koji channels which will be used by odcs main/children pungi runroot tasks
by Jan Kaluža 12 Apr '19

12 Apr '19

jkaluza reported a new issue against the project: `releng` that you are following: `` This is follow-up of meeting we have with @Kellin, @puiteriwjk, @mboddu, @ralph and others about using ODCS for alpha/beta composes. More info about motivation can be found here: https://docs.google.com/document/d/1VLOgxmdHL6eXMK1dZAsimJ1U3gtppntdeQkM-x8… In order to make ODCS scalable and keep using read-only access for /mnt/fedora_koji, we decided to run ODCS tasks in Koji runroot. We need to prevent deadlock scenario, when main runroot task with main pungi "process" submits to Koji another children runroot tasks (for example for buildinstall phase), but Koji would not have enough buiders for these runroot tasks ready. It has been advised that we could fix that by using different Koji channels for main pungi runroot task (this is submitted by ODCS backend) and children pungi runroot tasks (these are submitted by Pungi main runroot task). This request is official ticket asking for two new Koji channel. First one (for example "odcs"), to be used by ODCS backend process to spawn the main Pungi runroot. Second one (for example "odcs-pung") to be used by main Pungi runroot to spawn children runroot tasks. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7195

3 3

[releng] Issue #7194: ODCS: Create secret private volume to share secrets between Koji runroot tasks.
by Jan Kaluža 12 Apr '19

12 Apr '19

jkaluza reported a new issue against the project: `releng` that you are following: `` This is follow-up of meeting we have with @Kellin, @puiteriwjk, @mboddu, @ralph and others about using ODCS for alpha/beta composes. More info about motivation can be found here: https://docs.google.com/document/d/1VLOgxmdHL6eXMK1dZAsimJ1U3gtppntdeQkM-x8… In order to make ODCS scalable and keep using read-only access for /mnt/fedora_koji, we decided to run ODCS tasks in Koji runroot. That means that even the pungi running in Koji runroot task needs to be able to spawn another runroot task and therefore it needs some secret files like keytab. The advised solution for that was creating new secret volume which could be mounted in ODCS pungi runroot task and pungi in that runroot task can read kerberos keytab from that storage. ODCS backend/frontend would not have access to that directory. This ticket is official request for such storage. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7194

3 3

[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

[releng] Issue #7079: reset 27 atomic host ostree repo
by Dusty Mabe 12 Apr '19

12 Apr '19

dustymabe reported a new issue against the project: `releng` that you are following: `` We are currently using smart versioning for our ostree repo in Fedora 27 (i.e. using `"version": '!OSTREE_VERSION_FROM_LABEL_DATE_TYPE_RESPIN'` feature of pungi). Since we have not yet completed the work to move bodhi to pungi from mash we need to go back to not smart versioning like we were doing in previous releases for now. I'll open a PR against pungi-fedora for this. In order to do this we need the repo to be reset. This can be as simple as removing just the refs `fedora/27/${basearch}/atomic-host`. Extra credit would be to also prune the repo so that we drop content we no longer care about. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7079

5 12

[releng] Issue #7071: libcrypt-nss-2.26-8.fc27.i686 missing from Fedora 27 x86_64 compose
by Florian Weimer 12 Apr '19

12 Apr '19

fweimer reported a new issue against the project: `releng` that you are following: `` The multlib RPM went missing: $ rsync rsync://ftp-stud.hs-esslingen.de/fedora/linux/updates/testing/27/x86_64/l/ | grep libcrypt -rw-r--r-- 74,352 2017/09/15 12:51:44 libcrypt-2.26-8.fc27.i686.rpm -rw-r--r-- 73,492 2017/09/15 12:53:17 libcrypt-2.26-8.fc27.x86_64.rpm -rw-r--r-- 66,192 2017/09/15 12:50:54 libcrypt-nss-2.26-8.fc27.x86_64.rpm This currently breaks updates, see [#1495431](https://bugzilla.redhat.com/show_bug.cgi?id=1495431). `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7071

6 26

← Newer
1
...
7
8
9
10
11
12
13
...
24
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

rel-eng January 2019