#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
#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
#6385: [RFE] provide unique product name in .treeinfo
-----------------------------+------------------------
Reporter: bpeck | Owner: rel-eng@…
Type: enhancement | Status: new
Milestone: Fedora 24 Alpha | Component: other
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
Currently nightly composes all produce the same name in product section of
.treeinfo
Adding <DATE>-<SPIN> to the name would be one way to solve this.
This would make rsyncing and testing clearer about which product is being
synced/tested.
Thank you
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6385>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#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
#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
#6387: epel7-kde build target
---------------------+------------------------
Reporter: rdieter | Owner: rel-eng@…
Type: task | Status: new
Milestone: | Component: koji
Keywords: | Blocked By:
Blocking: |
---------------------+------------------------
kde-sig will soon begin work on bringing kde frameworks 5 to epel7, and
doing so would be much easier (avoiding ~40 manual overrides) if we had a
build target, similar to fedora's f23-kde, to make it happen.
Thanks.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6387>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#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