rel-eng July 2016

rel-eng@lists.fedoraproject.org

9 participants
63 discussions

#6344: Strange issue on php-JsonSchema-1.6.1-1.fc22
by Fedora Release Engineering 14 Nov '16

14 Nov '16

#6344: Strange issue on php-JsonSchema-1.6.1-1.fc22 -----------------------------+------------------------ Reporter: remi | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 24 Alpha | Component: koji Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ Yesterday, I received a bodhi notification: php-JsonSchema-1.6.1-1.fc22 ejected from the push because u"Cannot find relevant tag for php-JsonSchema-1.6.1-1.fc22. None of ['f22-updates- testing', 'f22-updates-testing-pending'] are in [u'epel7-testing- candidate', u'dist-6E-epel-testing-candidate', u'dist-5E-epel-testing- candidate', u'f22-updates-candidate', u'f23-updates-candidate', u'f21 -updates-candidate']." According to http://koji.fedoraproject.org/koji/buildinfo?buildID=713713 Pakage is tag f22-updates-testing According to https://bodhi.fedoraproject.org/updates/FEDORA-2016-59f94c4aea Update is "locked" and pending. Can you please check ? -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6344> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 6

#6411: qtpass: request for stable open for 13 days
by Fedora Release Engineering 14 Nov '16

14 Nov '16

#6411: qtpass: request for stable open for 13 days -----------------------------+------------------------ Reporter: daveo | Owner: rel-eng@… Type: defect | Status: new Milestone: Fedora 24 Alpha | Component: mash Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ I made a new package [https://apps.fedoraproject.org/packages/qtpass/overview/ qtpass] which seems to be having some problems. The stable request in bodhi has been open for 13 days for both [https://bodhi.fedoraproject.org/updates/FEDORA-2016-52d9d7d25f f22] and [https://bodhi.fedoraproject.org/updates/FEDORA-2016-52d9d7d25f f23]. And according to the [https://apps.fedoraproject.org/packages/qtpass/overview/ overview] the package seems to be in both the testing and stable repositories for f24. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6411> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 2

#6431: gcc.x86_64.rpm conflicts with gcc.i686.rpm
by Fedora Release Engineering 14 Nov '16

14 Nov '16

#6431: gcc.x86_64.rpm conflicts with gcc.i686.rpm -----------------------------+------------------------ Reporter: mcermak | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 24 Alpha | Component: koji Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ The gcc.x86_64.rpm conflicts with gcc.i686.rpm. Please refer to: https://bugzilla.redhat.com/show_bug.cgi?id=1346924 -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6431> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 1

#6439: new fedora 24 atomic composes not working
by Fedora Release Engineering 14 Nov '16

14 Nov '16

#6439: new fedora 24 atomic composes not working -----------------------------+------------------------ Reporter: kevin | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 24 Alpha | Component: koji Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ Recently, bodhi enabled f24 updates and updates-testing atomic composes. However, it's failing to work due to a missing ostree repo in /mnt/koji/mash/atomic/24/ This repo is rsynced by bodhi before the compose starts. It's unclear if this needs to be a new empty repo, the last fedora 24 release repo, or the two week atomic repo. {{{ Running ['/usr/bin/rsync', '-rvp', '--ignore-existing', '/mnt/koji/mash/atomic/24/objects/', '/srv/fedora-atomic/24/x86_64/docker- host/objects/'] 2016-07-08 17:03:51,759 - ERROR - composer.py:209 - rsync: change_dir "/mnt/koji/mash/atomic/24/objects" failed: No such file or directory (2) }}} We need to figure out what repo should be there and make sure its copied there or bodhi knows how to make it if it doesn't exist. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6439> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 5

#6444: qmapshack-1.6.3-1.el7 ejected from the push
by Fedora Release Engineering 14 Nov '16

14 Nov '16

#6444: qmapshack-1.6.3-1.el7 ejected from the push -----------------------------+------------------------ Reporter: sharkcz | Owner: rel-eng@… Type: defect | Status: new Milestone: Fedora 25 Alpha | Component: koji Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ For couple days I'm getting an error for my qmapshack update in EPEL from the notification email: The following comment has been added to the qmapshack-1.6.3-1.el7 update: bodhi - 2016-07-16 15:22:54.530535 (karma: 0) qmapshack-1.6.3-1.el7 ejected from the push because 'Request None inconsistent with mash request <testing>' To reply to this comment, please visit the URL at the bottom of this mail ================================================================================ qmapshack-1.6.3-1.el7 ================================================================================ Update ID: FEDORA-EPEL-2016-793b20946f Release: Fedora EPEL 7 Status: testing Type: bugfix Karma: 0 Notes: - updated to 1.6.3 with a critical (possible data loss) bug fix * : [Issue #147] Fix bug preventing list formats to be : removed * [Issue #148] Text editor: format of pasted : text * [Issue #149] Properly initialize cachePath for : systems without QMS configuration (new installations) : ---- - updated to 1.6.2 - see https://bitbucket.org/m : aproom/qmapshack/src/0696bf12af0f7c9bfb70c676c01dcffaf : bf48306/changelog.txt?fileviewer=file-view-default for : full changelog Submitter: sharkcz Submitted: 2016-07-14 12:46:05.568095 Comments: bodhi - 2016-07-14 12:46:05.573078 (karma 0) This update has been submitted for testing by sharkcz. bodhi - 2016-07-14 12:46:15.693289 (karma 0) This update has obsoleted [qmapshack-1.6.2-1.el7](http s://bodhi.fedoraproject.org/updates/FEDORA- EPEL-2016-defbccb8ca), and has inherited its bugs and notes. bodhi - 2016-07-15 07:47:20.169169 (karma 0) This update has been pushed to testing. bodhi - 2016-07-16 15:22:54.530535 (karma 0) qmapshack-1.6.3-1.el7 ejected from the push because 'Request None inconsistent with mash request <testing>' https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-793b20946f -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6444> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 1

#6184: suitesparse can't be installed in ppc64 el6 buildroots
by Fedora Release Engineering 07 Nov '16

07 Nov '16

#6184: suitesparse can't be installed in ppc64 el6 buildroots -----------------------------+------------------------ Reporter: rmattes | Owner: rel-eng@… Type: defect | Status: new Milestone: Fedora 23 Final | Component: epel Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ I'm running into trouble building GeographicLib in epel6. GeographicLib requires octave, which in turn requires suitesparse. It looks like suitesparse was in epel for a while, but got absorbed into rhel at some point and blocked from the buildroots. Since centos doesn't provide ppc64 packages, the ppc64 octave package in epel now has missing dependencies on suitesparse libraries and can't be installed in koji. What's the best way forward for this issue? Is it to: - Unblock the epel6 suitesparse and make it exclusivearch ppc64? - Rebuild all of the dependencies of suitesparse to excludearch ppc64? - Make octave-GeographicLib excludearch ppc64 and ignore the issue entirely? Please advise. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6184> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 3

#6348: Missing suitesparse-3.4.0-9.el6 ppc64 package
by Fedora Release Engineering 07 Nov '16

07 Nov '16

#6348: Missing suitesparse-3.4.0-9.el6 ppc64 package --------------------+------------------------ Reporter: ellert | Owner: rel-eng@… Type: task | Status: new Milestone: | Component: epel Keywords: | Blocked By: Blocking: | --------------------+------------------------ The octave package is not installable in EPEL 6 ppc64: https://kojipkgs.fedoraproject.org//work/tasks/1598/12901598/root.log {{{ DEBUG util.py:399: Error: Package: 6:octave-3.4.3-1.el6.ppc64 (build) DEBUG util.py:399: Requires: libamd.so.2()(64bit) DEBUG util.py:399: Error: Package: 6:octave-3.4.3-1.el6.ppc64 (build) DEBUG util.py:399: Requires: libcolamd.so.2()(64bit) DEBUG util.py:399: Error: Package: 6:octave-3.4.3-1.el6.ppc64 (build) DEBUG util.py:399: Requires: libcamd.so.2()(64bit) DEBUG util.py:399: Error: Package: 6:octave-3.4.3-1.el6.ppc64 (build) DEBUG util.py:399: Requires: libumfpack.so.5()(64bit) DEBUG util.py:399: Error: Package: 6:octave-3.4.3-1.el6.ppc64 (build) DEBUG util.py:399: Requires: libcholmod.so.1()(64bit) DEBUG util.py:399: Error: Package: 6:octave-3.4.3-1.el6.ppc64 (build) DEBUG util.py:399: Requires: libccolamd.so.2()(64bit) DEBUG util.py:399: Error: Package: 6:octave-3.4.3-1.el6.ppc64 (build) DEBUG util.py:399: Requires: libcxsparse.so.2()(64bit) }}} On x86_64 and i686 these are provided by suitesparse-3.4.0-9.el6. The suitesparse package is provided by RHEL, but it seems to be missing for ppc64. There is an older version suitesparse-3.4.0-2.el6 provided by EPEL, but since this has a lower NVR than the RHEL version it is not used in the koji build roots. This was the version that was used to build the octave package for EPEL 6 ppc64. It looks like when the suitesparse package started being provided by RHEL 6 and the EPEL 6 package was retired, the ppc64 version of the package got lost. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6348> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 5

#6313: atomic host: reorienting ostree commits to match 2 week cadence
by Fedora Release Engineering 14 Oct '16

14 Oct '16

#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

1 17

#6195: Signed commits for ostree / Project Atomic
by Fedora Release Engineering 03 Oct '16

03 Oct '16

#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

1 2

#6267: sign ostree commits
by Fedora Release Engineering 03 Oct '16

03 Oct '16

#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

1 11

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

rel-eng July 2016