#6219: Need updated cloud images for Fedora 22
-----------------------------+------------------------
Reporter: kushal | Owner: rel-eng@…
Type: task | Status: new
Milestone: Fedora 22 Final | Component: other
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
Hi,
I have tested the following tree with the formal tests. Please do a
release of the updated cloud images from this tree.
http://alt.fedoraproject.org/pub/alt/stage/22-20150720/Cloud-
Images/x86_64/Images/
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6219>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#6252: please create a rawhide and f23 side tag for llvm updates
-----------------------------+------------------------
Reporter: airlied | Owner: rel-eng@…
Type: task | Status: new
Milestone: Fedora 23 Final | Component: git
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
Hi guys,
I want to update llvm to 3.7 in rawhide and f23, but I'd like to build all
the deps in a side tag first to make sure.
Can you create two tags?
Dave.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6252>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#6355: Latest createImage task used old spin-kickstarts commit
-----------------------------+------------------------
Reporter: jlebon | Owner: rel-eng@…
Type: task | Status: new
Milestone: Fedora 24 Alpha | Component: koji
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
The latest Fedora Cloud Atomic 23 image released yesterday was produced
from an out of date kickstart file. The associated koji task is:
http://koji.fedoraproject.org/koji/taskinfo?taskID=13102744
Judging by the name of the ks file ("fedora-cloud-atomic-2878aa0.ks"), it
seems like it used commit 2878aa0 of the spin-kickstarts repo, which is
*not* the current HEAD (current HEAD is 6641de0, committed 5 days ago).
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6355>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#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
#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
#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
#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
#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
#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