#6184: suitesparse can't be installed in ppc64 el6 buildroots
by Fedora Release Engineering
#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
6 years, 6 months
#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
6 years, 8 months
#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
6 years, 11 months
#6196: Please build F22 Atomic images nightly
by Fedora Release Engineering
#6196: Please build F22 Atomic images nightly
-----------------------------+------------------------
Reporter: mattdm | Owner: rel-eng@…
Type: task | Status: new
Milestone: Fedora 22 Final | Component: koji
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
This is a followup to mailing list conversation
https://lists.fedoraproject.org/pipermail/cloud/2015-May/005351.html — see
that for some background.
In short, as per normal, F22 image builds stopped at F22 release. However,
for Atomic, we'd like to actually keep going, with new images built with
the released installer but pointing at the latest, new Atomic tree every
night.
Basically, run the same task as
http://koji.fedoraproject.org/koji/taskinfo?taskID=9832787 nightly, with
all of the same options, except use the latest Atomic kickstart in the
spin-kickstarts F22 branch.
(This would be for both fedora-cloud-atomic.ks and fedora-cloud-atomic-
vagrant.ks.)
The kickstarts will be updated to point at the correct new nightly tree.
I know there's work on a better world where this is done with Pungi 4, but
I hope we can find a quick solution which doesn't block on that.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6196>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
7 years, 8 months
#6197: Request for f23-boost dist tag
by Fedora Release Engineering
#6197: Request for f23-boost dist tag
-----------------------------+------------------------
Reporter: jwakely | Owner: rel-eng@…
Type: task | Status: new
Milestone: Fedora 23 Final | Component: koji
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
In order to rebase Boost for F23 could I please have a side tag for
rebuilding the Boost dependencies. The approved change is here:
https://fedoraproject.org/wiki/Changes/F23Boost159
I will initially rebuild everything with Boost 1.58 and if Boost 1.59 is
released on schedule then I'll rebase to 1.59 and rebuild again.
Upstream Boost 1.59 is expect to be frozen early August and released on
Wednesday August 12th, according to
http://www.boost.org/development/index.html, so the tag will be needed
until then.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6197>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
7 years, 10 months
#6203: f22-kde koji target
by Fedora Release Engineering
#6203: f22-kde koji target
---------------------+----------------------
Reporter: rdieter | Owner: rdieter
Type: task | Status: new
Milestone: | Component: koji
Keywords: | Blocked By:
Blocking: |
---------------------+----------------------
I've init'd f22-kde koji target to build plasma-5.3.2
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6203>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
7 years, 10 months
[distgit] Moving to sha512, next step
by Mathieu Bridon
Hi,
As per the latest status report in the ticket [1], I'd like to move
forward with the next step.
I'd like to have all existing source files hardlinked to their new
path, from:
/$module/$source/$hash/$sources
To:
/$module/$source/md5/$hash/$sources
Doing this makes it easier to continue with the changes to fedpkg:
1. all files uploaded since June 5 exist both at the old and new paths
2. all files uploaded before only exist at the old path
3. fedpkg currently downloads from the old path, but we'll eventually
make it download from the new path
If we changed fedpkg right now, then it needs to try downloading at the
new path, and if that fails, fallback on the old path. I have code
doing just that ready to be sent as a pull request if needed.
However, if we first hardlink all existing source files to the new
path, then we don't even need the fallback in fedpkg, which makes the
code much simpler.
Note: hardlinking to the sha512 path can come at a later stage, for
now I am only talking about hardlinking to the new md5 path.
Attached is an Ansible patch that adds a script I wrote, which iterates
over all source files in the lookaside cache, and:
- if the file is at the old path, verify its md5 and hardlink it to
the new path
- if the file is at the new path, just verify its md5
I ran that script in staging with a limited subset of the lookaside
cache [2] and it did the job.
I'd like some review of the script first, and then someone to run it in
production. The script won't do anything without the --perform option,
so it's safe to try it out first:
$ make-new-lookaside-links /srv/cache/lookaside/pkgs/
At that point I'd like a chance to review the output, to make sure
everything is going as expected. :)
When ready to actually do it: [3]
$ make-new-lookaside-links --perform /srv/cache/lookaside/pkgs/
I'm happy to discuss this more here on on IRC, and I'll try my best to
be available when someone runs it in production.
Thanks,
[1] https://fedorahosted.org/rel-eng/ticket/5846#comment:23
[2] all the 'ad*' packages, thanks to Ralph for syncing them over from
prod
[3] running the script with the --perform option requires doing so as a
user with write permission inside of /srv/cache/lookaside/pkgs/...
Either apache or root should work.
--
Mathieu
7 years, 10 months
#6183: RPMs from rhel-7-workstation-rpms not mentioned in pkg_el7.json
by Fedora Release Engineering
#6183: RPMs from rhel-7-workstation-rpms not mentioned in pkg_el7.json
-----------------------------+------------------------
Reporter: robert | Owner: rel-eng@…
Type: task | Status: new
Milestone: Fedora 22 Final | Component: epel
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
According to my knowledge,
https://infrastructure.fedoraproject.org/repo/json/pkg_el7.json is the
base for checking if a package is already part of RHEL 7 (if it's listed
there it's in RHEL 7). However, the packages libisofs and libburn are not
mentioned there at all, even they are in RHEL 7 (rhel-7-workstation-rpms).
But why?
As result, branching the package for epel7, building and submitting as an
update was possible. Fortunately somebody mentioned in the Bodhi update
that the package is part of CentOS 7 (and thus likely of RHEL 7).
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6183>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
7 years, 10 months
#6204: Please un-retire yaws
by Fedora Release Engineering
#6204: Please un-retire yaws
-----------------------------+------------------------
Reporter: lkundrak | Owner: rel-eng@…
Type: task | Status: new
Milestone: Fedora 22 Final | Component: koji
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
Hello,
yaws found a new maintainer has been unretired. Please unblock the package
(at least for Fedora 23).
Thank you!
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6204>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
7 years, 10 months