March 2016 - rel-eng - Fedora Mailing-Lists

#6313: atomic host: reorienting ostree commits to match 2 week cadence

by Fedora Release Engineering

#6313: atomic host: reorienting ostree commits to match 2 week cadence -----------------------------+------------------------ Reporter: walters | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 23 Final | Component: other Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ Current as I understand it, we have a "two week" process for images (cloud, ISO etc.), but the OSTree commits are made at the default Fedora at-most-once-a-day cadence. I would like to propose doing only one released OSTree commit matching the two week release. Meaning `atomic host upgrade` would exactly what the images give. The advantage of this is predictability. NOTE: we need an exception for critical async security errata. The /testing/ ref though would continue at its current rate - and ideally go even faster. I would be a lot happier if we skipped the manual once-a-day RPM signing and did direct Koji -> /testing/. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6313> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

7 years, 6 months

1
17
0 / 0

#6195: Signed commits for ostree / Project Atomic

by Fedora Release Engineering

#6195: Signed commits for ostree / Project Atomic -----------------------------+------------------------ Reporter: mattdm | Owner: rel-eng@… Type: enhancement | Status: new Milestone: Fedora 23 Alpha | Component: other Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ As Atomic moves from experimental to something users will actually depend on, we need to get this right. It's my understanding that the current workflow doesn't make it easy (the signing needs to happen in a place different from what we're used to). I don't know the specifics, but as Dennis says, "we should figure something out. I just do not know what a good answer is". The same thing might let us also sign RPM repo metadata. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6195> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

7 years, 6 months

1
2
0 / 0

#6267: sign ostree commits

by Fedora Release Engineering

#6267: sign ostree commits -----------------------------+------------------------ Reporter: walters | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 23 Final | Component: koji Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ This has been discussed several times. AIUI it is blocked on a Fedora policy of not doing detached signatures. As downstream Red Hat Enterprise Linux and its associated PST are OK with detached signatures, I think Fedora should as well. The GPG signature would have helped mitigate https://git.fedorahosted.org/cgit/spin- kickstarts.git/commit/?id=1e408e111008f539c89212a9ca9bb955e2c4f823 for example. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6267> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

7 years, 6 months

1
11
0 / 0

#6350: integrate atomic (host and other) CI/CD into Fedora

by Fedora Release Engineering

#6350: integrate atomic (host and other) CI/CD into Fedora -----------------------------+------------------------ Reporter: walters | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 24 Alpha | Component: other Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ Breaking out from: https://fedorahosted.org/rel-eng/ticket/6313 Let's define a system and process for CD (Continuous Delivery) that bypasses manual integration via Koji/Bodhi and ships as quickly as possible to a small audience on dl.fedoraproject.org. Specifically, use rpmdistro-gitoverlay to mirror upstream sources that we know have been peer reviewed already, and build/ship them automatically. Also generate a devel/ ostree ref based on this content, and potentially images. Integrate pull request testing into this too. Resources required: - OpenStack tenant resources - Ability to write to dl.fedoraproject.org somewhere -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6350> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

7 years, 6 months

1
9
0 / 0

#6304: ability to test spin-kickstars by doing throw away image builds in koji

by Fedora Release Engineering

#6304: ability to test spin-kickstars by doing throw away image builds in koji -----------------------------+------------------------ Reporter: dustymabe | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 23 Final | Component: koji Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ It would be nice to be able to create image builds in koji that are throw away builds that are purely used for testing of changes to kickstart files etc.. The idea is that we would use these as a way to test our changes before officially commiting them to the spin-kickstarts repo. Having this ability would mean it is much easier for contributors to test changes and thus more likely to submit fixes and or suggestions back. We can currently do an image build on our own machines but it does take some setup and it is not the same environment as the one in koji. So, while we can test on our own machines, is it a valid test? Not really. I would love this functionality. I know it might not technically be possible right now to do, but we shouldn't ignore its value and should perhaps take steps to get there. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6304> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

7 years, 7 months

1
12
0 / 0

#6200: Cannot mirror Fedora drpms using OpenAFS

by Fedora Release Engineering

#6200: Cannot mirror Fedora drpms using OpenAFS -----------------------------+------------------------ Reporter: tc01 | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 22 Final | Component: other Keywords: meeting | Blocked By: Blocking: | -----------------------------+------------------------ I had (mistakenly) filed this against infrastructure: https://fedorahosted.org/fedora-infrastructure/ticket/4798 To summarize: we'd like to run a Fedora mirror in an OpenAFS cell, but the drpms/ directory is far larger than the 64K slot limit in OpenAFS and, as a result, cannot mirror them. We are currently just excluding the drpms, which works, but I'd like to be able to mirror them if possible. A couple of possible fixes are mentioned in the discussion on that ticket; keeping fewer drpms, or organizing the drpms into alphabetical subdirectories instead of one giant drpms/ directory. How does rel-eng feel about this? Is this something that could be fixed in some way or should we merely continue to exclude the drpms? Thanks in advance. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6200> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

7 years, 9 months

1
6
0 / 0

#6333: delete errant rhos-8.0-rhel-7 from erlang dist-git

by Fedora Release Engineering

#6333: delete errant rhos-8.0-rhel-7 from erlang dist-git ----------------------+------------------------ Reporter: jeckersb | Owner: rel-eng@… Type: task | Status: new Milestone: | Component: git Keywords: | Blocked By: Blocking: | ----------------------+------------------------ I accidentally pushed a rhos-8.0-rhel-7 branch to the fedora remote on the erlang repo, and the commit hook won't let me delete it by pushing an empty ref overtop. Please delete this branch manually (or better, tell me how to delete it if I can do it myself! http://pkgs.fedoraproject.org/cgit/rpms/erlang.git/log/?h=rhos-8.0-rhel-7 Thanks! -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6333> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

7 years, 9 months

1
2
0 / 0

#6261: Create secondary release staging SOP

by Fedora Release Engineering

#6261: Create secondary release staging SOP -----------------------------+------------------------ Reporter: till | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 23 Final | Component: other Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ Should be similar to the one for primary I guess: https://fedoraproject.org/wiki/Stage_final_release_for_mirrors It came up when I noticed that the CHECKSUM files for secondary test releases are not signed: https://dl.fedoraproject.org/pub/fedora- secondary/releases/test/23_Alpha/Server/ppc64le/iso/Fedora-Server-23 -ppc64le-CHECKSUM -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6261> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

7 years, 9 months

1
1
0 / 0

#6370: F24 stable push requests

by Fedora Release Engineering

#6370: F24 stable push requests -----------------------------+------------------------ Reporter: adamwill | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 24 Final | Component: koji Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ This ticket will be used for requesting pushes of tested blocker / freeze exception fixes during F23 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 TC/RC request tickets, this ticket can be closed by releng after each push and re-opened by QA each time a new push is needed. First request: [https://bodhi.fedoraproject.org/updates/FEDORA-2016-64146d940c systemd-229-6.fc24] for [https://bugzilla.redhat.com/show_bug.cgi?id=1313085 #1313085] . I've been trying to build a live image with livemedia-creator to test the fix, but haven't had any luck getting it to run at all, so I figure we can push the update stable and see how the next round of nightlies looks. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6370> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

7 years, 10 months

1
32
0 / 0

#6372: secondary sync scripts have issues with src.rpm syncing

by Fedora Release Engineering

#6372: secondary sync scripts have issues with src.rpm syncing -----------------------------+------------------------ Reporter: kevin | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 24 Alpha | Component: koji Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ Mar 15 19:17:30 arm-hub01.qa.fedoraproject.org rsyncd[53390]: rsync: change_dir "/development/rawhide/Everything/source/SRPMS/h" (in fedora- arm) failed: No such file or directory (2) arm appears to have a dir named 'tree' under source/ not SRPMS. Mar 15 20:27:27 s390-koji01.qa.fedoraproject.org rsyncd[29705]: rsync: link_stat "/updates/23/s390x/p/php-pecl-libsodium-1.0.2-1.fc23.src.rpm" (in fedora-s390) failed: No such file or directory (2) s390 src.rpms are in /updates/N/SRPMS/ not /updates/N/s390x/x/src.rpm https://pagure.io/releng/blob/master/f/scripts/secondary-sync.py#_202 is the script that does the syncing. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6372> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

7 years, 11 months

1
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

rel-eng March 2016