rel-eng June 2018

rel-eng@lists.fedoraproject.org

7 participants
240 discussions

[pungi-fedora] PR #598: Fedora Minimal Compose for OpenQA testing
by Mohan Boddu 09 Mar '21

09 Mar '21

mohanboddu opened a new pull-request against the project: `pungi-fedora` that you are following: `` Fedora Minimal Compose for OpenQA testing `` To reply, visit the link below or just reply to this email https://pagure.io/pungi-fedora/pull-request/598

5 20

[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] PR #502: WIP: Add fedora-atomic-ws config
by Colin Walters 08 Mar '21

08 Mar '21

walters opened a new pull-request against the project: `pungi-fedora` that you are following: `` WIP: Add fedora-atomic-ws config `` To reply, visit the link below or just reply to this email https://pagure.io/pungi-fedora/pull-request/502

6 20

[pungi-fedora] Issue #501: Mark compiler-rt as multilib
by Tom Stellard 26 Jan '21

26 Jan '21

tstellar reported a new issue against the project: `pungi-fedora` that you are following: `` The i686 packages for compiler-rt are no longer available in the x86_64 repositories starting with Fedora 27. Could you mark this package as multilb. See https://bugzilla.redhat.com/show_bug.cgi?id=1513286 `` To reply, visit the link below or just reply to this email https://pagure.io/pungi-fedora/issue/501

2 3

[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

[releng] Issue #7555: permission to build livecd for minishift
by Praveen Kumar 10 Sep '19

10 Sep '19

kumarpraveen reported a new issue against the project: `releng` that you are following: `` I am part of minishift[0] development team and currently, we only have support for CentOS and RHEL live iso to provision Openshift locally, we also want to add support for Fedora iso so people can try the latest development around container world. As a starting point we only first try the scratch build of the iso with f28/f29/rawhide. ``` $ klist Ticket cache: KEYRING:persistent:1000:1000 Default principal: kumarpraveen(a)FEDORAPROJECT.ORG Valid starting Expires Service principal 06/08/2018 12:31:28 06/09/2018 12:28:38 HTTP/koji.fedoraproject.org(a)FEDORAPROJECT.ORG renew until 06/15/2018 12:28:32 06/08/2018 12:28:38 06/09/2018 12:28:38 krbtgt/FEDORAPROJECT.ORG(a)FEDORAPROJECT.ORG renew until 06/15/2018 12:28:32 $ koji spin-livecd --scratch minishift-fedora 1.0.0 rawhide x86_64 fedora.ks spin-livecd is deprecated and will be replaced with spin-livemedia [====================================] 100% 00:00:00 19.70 KiB 33.12 KiB/sec ActionNotAllowed: livecd permission required ``` [0] https://github.com/minishift/minishift `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7555

5 15

[releng] Issue #7477: Changes for release SOP before f29
by Kevin Fenzi 10 Sep '19

10 Sep '19

kevin reported a new issue against the project: `releng` that you are following: `` This ticket will collect any changes we need to make to the release SOP that were missed in f28 but we should add in f29. We should collect them here and then close this once all of them are merged into the SOP. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7477

5 9

[releng] Issue #7428: Anaconda & bodhi update improvements
by Martin Kolman 10 Sep '19

10 Sep '19

m4rtink reported a new issue against the project: `releng` that you are following: `` I would like to start by saying that the Bodhi update process works just fine for Anaconda during freeze periods - we just build a new version of Anaconda or any of it's related packages with all the blocker a FE fixes, put it to an update and basically hand it over to Fedora QA, who handle the rest (make sure it ends up in the appropriate compose, etc.). Where I think the Bodhi process does not really work are the periods when Fedora is not in freeze (so after Bodhi activation and before Beta freeze and after Beta freeze and before Final freeze). As regular users are rather unlikely to test Installer updates (with the whole "you need to reinstall your machine to test it" thing) so the Anaconda updates generally sit there for the full 7 days (+any Bodhi push overhead) and are then pushed to stable possibly without any testing. Also any changes to the update, such as adding a fixed build or adding additional packages reset karma and (IIRC) also the waiting period. Given that the no-freeze period are generally about two weeks, it's actually pretty challenging to get any regular Anaconda updated to stable at all. This can then result in users getting 6+ weeks (4 weeks freeze, 1-2 weeks in Bodhi) of changes at once, possibly right before the next freeze. Or the update might not even make it in before the next freeze has started due to all the delays, complicating maters further. I'm not sure if there is a simple solution for this (other than "go bother Adam/Fedora QA for each update") but it would be ideal if each Anaconda update would both: - get some actual testing (other than our unit tests/CI) - would reach composes much sooner, making it possible to do more smaller releases outside of the freeze period, making the discovery and fixing of release blocking issues more likely before they can wreak havoc during the freeze period Maybe some more automated CI & some notification mechanism for Fedora QA that fires when new updates for Anaconda shows up ? Ideally with some commitment to tests it & push to stable if it looks fine. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7428

3 4

[releng] Issue #7337: Emit fedmsg when candidate composes are synced to stage
by Adam Williamson 10 Sep '19

10 Sep '19

adamwill reported a new issue against the project: `releng` that you are following: `` Candidate composes (as opposed to nightly composes) for Branched are synced to https://dl.fedoraproject.org/pub/alt/stage/ after they're built. This is supposed to be the preferred download location for them (rather than kojipkgs). However, there is currently no fedmsg emitted when this happens, so automated systems have no good way to know when a candidate compose has been synced and is available from stage/. It would be good if there was a fedmsg for this (probably a `compose` one). @puiterwijk `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7337

3 4

[releng] Issue #7588: F29 system wide change: Deprecate YUM 3 - request for review
by Daniel Mach 05 Sep '19

05 Sep '19

dmach reported a new issue against the project: `releng` that you are following: `` I'd like to request review of F29 system wide change: Deprecate YUM 3 https://fedoraproject.org/wiki/Changes/Deprecate_YUM_3 `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7588

9 15

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

rel-eng June 2018