April 2016 - rel-eng - Fedora Mailing-Lists

#6398: Retired but still tagged builds in f24

by Fedora Release Engineering

#6398: Retired but still tagged builds in f24 -----------------------------+------------------------ Reporter: apevec | Owner: rel-eng@… Type: defect | Status: new Milestone: Fedora 24 Final | Component: koji Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ I've retired openstack packages in f24, but some builds are still left tagged f24, please untag them: openstack-designate-1.0.0-0.2.0b3.fc24 openstack-designate-1.0.0-0.3.0b3.fc24 openstack-designate-2015.1.0-2.fc23 openstack-gnocchi-1.3.0-3.fc24 openstack-gnocchi-1.3.0-4.fc24 openstack-gnocchi-1.3.0-5.fc24 openstack-heat-5.0.0-1.fc24 openstack-heat-5.0.0-2.fc24 openstack-heat-5.0.0-3.fc24 openstack-heat-gbp-2014.2-2.fc23 openstack-heat-gbp-2015.1.1-1.fc24 openstack-heat-gbp-2015.1.1-2.fc24 openstack-heat-templates-0-0.3.20141111git.fc23 openstack-heat-templates-0-0.4.20141111git.fc24 openstack-manila-1.0.0-2.fc24 openstack-manila-1.0.0-3.fc24 openstack-manila-1.0.0-4.fc24 openstack-manila-ui-1.0.1-1.fc23 openstack-manila-ui-1.0.1-2.fc24 openstack-marconi-2014.1-3.fc23.2 openstack-marconi-2014.1-4.fc24.2 openstack-neutron-gbp-2015.1.1-1.fc24 openstack-neutron-gbp-2015.1.1-2.fc24 openstack-neutron-gbp-2015.2.0-1.fc24 openstack-packstack-7.0.0-0.10.dev1682.g42b3426.fc24 openstack-packstack-7.0.0-0.11.dev1692.g1b5e83b.fc24 openstack-packstack-7.0.0-0.12.dev1692.g1b5e83b.fc24 openstack-puppet-modules-7.0.0-1.fc24 openstack-puppet-modules-7.0.1-1.fc24 openstack-puppet-modules-7.0.6-1.fc24 openstack-sahara-2015.1.0-2.fc23 openstack-sahara-3.0.0-0.2.0rc1.fc24 openstack-sahara-3.0.0-2.fc24 openstack-swift-2.4.0-1.fc24 openstack-swift-2.5.0-1.fc24 openstack-swift-2.5.0-2.fc24 openstack-swift-plugin-swift3-1.7-6.20150601git69f94393.fc23 openstack-swift-plugin-swift3-1.9-1.fc24 openstack-swift-plugin-swift3-1.9-2.fc24 openstack-tempest-kilo-20150708.2.fc23 openstack-tempest-liberty-20151020.1.fc24 openstack-tempest-liberty-20151020.2.fc24 openstack-tripleo-0.0.5-3c3fb309727671130a32b4c19de48ec22c8530aa1.fc23 openstack-tripleo-0.0.5-4c3fb309727671130a32b4c19de48ec22c8530aa1.fc24 openstack-tripleo-heat-templates-0.7.9-13.fc23 openstack-tripleo-heat-templates-0.7.9-14.fc24 openstack-tripleo-image-elements-0.8.10-20.fc23 openstack-tripleo-image-elements-0.8.10-21.fc24 openstack-tuskar-ui-0.2.0-5.fc22 openstack-utils-2014.2-1.fc23.1 openstack-utils-2015.2-1.fc24 openstack-utils-2015.2-1.fc24.1 openstack-zaqar-1.0.0-0.1.0rc2.fc24.1 openstack-zaqar-1.0.0-1.fc24 openstack-zaqar-1.0.0-2.fc24 -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6398> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

7 years, 9 months

1
10
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

#6393: Bogus "broken dependencies in the rawhide tree" notifications

by Fedora Release Engineering

#6393: Bogus "broken dependencies in the rawhide tree" notifications --------------------+------------------------ Reporter: ellert | Owner: rel-eng@… Type: task | Status: new Milestone: | Component: koji Keywords: | Blocked By: Blocking: | --------------------+------------------------ Hi. I keep getting copies of the following message. ``` root has broken dependencies in the rawhide tree: On x86_64: root-mathmore-5.34.32-8.fc24.x86_64 requires libgsl.so.0()(64bit) On i386: root-mathmore-5.34.32-8.fc24.i686 requires libgsl.so.0 Please resolve this as soon as possible. ``` This was fixed on 2016-04-11 with the successful build of root-6.06.02-1.fc25 https://koji.fedoraproject.org/koji/buildinfo?buildID=753202 Since it was fixed I keep getting more copied of this message, so far 7 of them. Why? I first though that there was a "typo" in the message, and that it was actually referring to Fedora 24, but this doesn't seem to be the case: root-6.06.02-1.fc24 was pushed to stable yesterday, and I still got a new copy of the message today. Why do I get these messages still? -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6393> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

7 years, 10 months

1
6
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

#6369: Please create a f24-gnome side tag

by Fedora Release Engineering

#6369: Please create a f24-gnome side tag -----------------------------+------------------------ Reporter: kalev | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 24 Alpha | Component: koji Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ Hi, Please create a new f24-gnome side tag and build target. We'll use it for building GNOME megaupdates before submitting them to Bodhi, to help ensure they don't cause issues in F24 proper while we're preparing the updates. Thanks, Kalev -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6369> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

7 years, 11 months

1
5
0 / 0

#6402: Bodhi is ignoring epoch

by Fedora Release Engineering

#6402: Bodhi is ignoring epoch -----------------------------+------------------------ Reporter: jussilehtola | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 24 Final | Component: mash Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ Problem: bodhi seems to be ignoring epoch in the determination of obsolete updates. Full description: There's an issue with segfaults in epson-inkjet-printer-escpr version 1.6.4. I updated the package to 1.6.5, and pushed out the update epson- inkjet-printer-escpr-1.6.5-1.1lsb3.2. However, I noticed that the file that was causing the crash had not been changed from 1.6.4 to 1.6.5. So, I introduced Epoch 1, rolled back the package to the 1.5.2 version, and pushed out the resulting epson-inkjet- printer-escpr-1.5.2-3.1lsb3.2 as updates. However, bodhi has marked the latter update, epson-inkjet-printer- escpr-1.5.2-3.1lsb3.2 (epoch 1), as being obsoleted by epson-inkjet- printer-escpr-1.6.5-1.1lsb3.2 (epoch 0). This should not happen, because 1:1.5.2-3.1lsb3.2 is newer than 0:1.6.5-1.1lsb3.2. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6402> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

7 years, 11 months

1
4
0 / 0

Fedora Docker Registry Proposal

by Adam Miller

Hello all, I have been working on a proposal on how to handle Fedora's Docker Registry requirements to deliver our future "docker-ized" content to users in a way that won't leave us with a bottleneck to the user community hitting a single download location. Below you will find that proposal and I would greatly appreciate feedback. The good news is I did a small PoC of the plan I would like to propose along with the workflow (simulating some steps in the process for brevity), and it all worked! The potentially bad news is that this introduces a reasonable amount of net-new services inside the Fedora Infrastructure. I wanted to sanity-check this proposal with the Rel-Eng crew and then send to the Infrastructure Team for feedback and advisement after I'm sure this makes sense to everyone from a rel-eng perspective. Thank you all in advance. Quick vocab background for Docker stuff: registry: a collection of docker image repositories repository: named after an image and is a collection of multiple tags of an that image tag: an arbitrary string assigned to a specific docker image (identified by the image's sha256 checksum) NOTE: The "latest" tag is special and is assumed if no tag is provided. This is true also for a 'docker pull' operation and an image tagged "latest" will be the default image pulled by users. Proposal: Pulp[0] + Crane[1] + MirrorManager[2] + Docker Distribution[3] Pulp is a platform for managing repositories of content, such as software packages, and making it available to a large numbers of consumers. It is also capable of managing docker content. Crane is a stand-alone python flask wsgi application written by the Pulp team to serve as a API entry point for the docker client and will answer to an user's 'docker pull'. It does not however create content manifests or provide hosting for docker image content, instead it depends on someone creating the manifest metadata themselves or having pulp publish it and serves 302 redirects to the docker client so they can find where the docker images actually live. I'll assume everyone here knows their way around MirrorManager. Docker Distribution is the defacto standard open source implementation of the Docker Registry V2 API spec[4]. It provides many features but the ability to have it's back-end storage be provided by a "mirror network" much like the one Fedora has at it's disposal is not one of them. The reason we need this in place is because the mechanism by which you could push a docker image directly to Pulp in Docker Registry v1 no longer exists in v2 so we must instead perform a "sync" operation between the two. (This is a common problem for all known "third party" v2 registry implementations). Workflow: OSBS will perform Builds, as these builds complete they will be pushed to the docker-distribution (v2) registry, these will be considered "candidate images". Pulp will sync and publish the candidate repository. Testing will occur using the "candidate images" (details of how we want to handle that are outside the scope of this proposal). A "candidate image" will be marked stable once it's criteria have been satisfied to do so. (This is vague because this is a topic of ongoing discussion and work to decide what criteria an image will need to abide by before being considered "stable" and promoted as such) Once stable, pulp will publish that repository's content to a directory, we will split that content and sync the image layers along with their metadata to Mirror Manager master mirror. We will also sync the repo metadata published by Pulp to somewhere Crane can pick it up. (This could and will likely be something that Bodhi triggers via the Pulp REST API) Mirror Manager will Pulp distribute to the mirrors the image layers and their metadata. Crane will get the new repository metadata and will serve redirects to the new content relative to download.fedoraproject.org which will perform another redirect (via MirrorManager) where the docker client upon a "docker pull" will find it's content. I have put together an ascii diagram in hopes that it will assist in seeing the full picture. https://maxamillion.fedorapeople.org/FedoraPulpDocker.txt (I couldn't get it to paste cleanly into my email client) If there are any questions, comments, or feedback please let me know. Thank you, -AdamM [0] - http://www.pulpproject.org/ [1] - https://github.com/pulp/crane [2] - https://github.com/fedora-infra/mirrormanager2/ [3] - https://github.com/docker/distribution/ [4] - https://docs.docker.com/registry/spec/api/

7 years, 11 months

6
8
0 / 0

#6405: Create Fedora 24 Beta candidates

by Fedora Release Engineering

#6405: Create Fedora 24 Beta candidates ----------------------------+------------------------ Reporter: adamwill | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 24 Beta | Component: koji Keywords: | Blocked By: Blocking: | ----------------------------+------------------------ We now need a Beta candidate build. This should fix all outstanding blocker bugs and thus is a 'release candidate' build. Please include: * [https://bodhi.fedoraproject.org/updates/kernel-4.5.2-302.fc24 kernel-4.5.2-302.fc24] for [https://bugzilla.redhat.com/show_bug.cgi?id=1321330 #1321330] * [https://bodhi.fedoraproject.org/updates/FEDORA-2016-1f7048425f libhif-0.2.2-3.fc24] for [https://bugzilla.redhat.com/show_bug.cgi?id=1259865 #1259865] * [https://bodhi.fedoraproject.org/updates/FEDORA-2016-9f5172b1c5 java-1.8.0-openjdk-1.8.0.91-2.b14.fc24] for [https://bugzilla.redhat.com/show_bug.cgi?id=1329342 #1329342] (FE) * [https://bodhi.fedoraproject.org/updates/FEDORA-2016-0f939ef633 firefox-46.0-4.fc24] for [https://bugzilla.redhat.com/show_bug.cgi?id=1315225 #1315225] (FE) Thanks! -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6405> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

7 years, 11 months

1
10
0 / 0

#6376: Missing administrators of several KDE packages

by Fedora Release Engineering

#6376: Missing administrators of several KDE packages -----------------------------+------------------------ Reporter: dvratil | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 24 Alpha | Component: other Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ Hi, shortly after group maintainership was introduced in pkgdb KDE SIG started using it. At some point we submitted several new packages where we set group::kde-sig as an owner. Back then pkgdb allowed that but the result is that now we have a bunch of packages with only group::kde-sig having approved ACLs and thus we are not able to add/approve new ACLs for them or manage the packages. Could you please add me (FAS dvratil) and Rex (FAS rdieter) as package administrators to the packages below? {{{ rpms/kaccounts-integration rpms/kaccounts-providers rpms/kde-cli-tools rpms/kdecoration rpms/kdeedu-data rpms/kf5-kfilemetadata rpms/kf5-kpackage rpms/kf5-kpeople rpms/kf5-kwayland rpms/kf5-kxmlrpcclient rpms/kf5-modemmanager-qt rpms/kf5-networkmanager-qt rpms/khelpcenter rpms/khotkeys rpms/kinfocenter rpms/kio-extras rpms/kmenuedit rpms/ksysguard rpms/kwrited rpms/libkeduvocdocument rpms/libkface rpms/libkgeomap rpms/libkscreen-qt5 rpms/libksysguard rpms/plasma-nm rpms/plasma-pk-updates rpms/plasma-workspace-wallpapers rpms/signon rpms/signon-kwallet-extension rpms/signon-plugin-oauth2 rpms/signon-ui }}} Thanks a lot. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6376> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

7 years, 11 months

1
4
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

rel-eng April 2016