rel-eng June 2015

rel-eng@lists.fedoraproject.org

12 participants
54 discussions

#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

#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

#6200: Cannot mirror Fedora drpms using OpenAFS
by Fedora Release Engineering 27 Jun '16

27 Jun '16

#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

1 6

#6196: Please build F22 Atomic images nightly
by Fedora Release Engineering 17 Sep '15

17 Sep '15

#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

1 4

#6182: Add Cinnamon spin to spin-kickstarts
by Fedora Release Engineering 10 Sep '15

10 Sep '15

#6182: Add Cinnamon spin to spin-kickstarts -----------------------------+------------------------ Reporter: grinnz | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 23 Alpha | Component: other Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ Add Cinnamon spin from this change proposal for F23: https://fedoraproject.org/wiki/Changes/Cinnamon_Spin Latest kickstarts here: https://github.com/Grinnz/spin-kickstart-cinnamon -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6182> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 2

#6197: Request for f23-boost dist tag
by Fedora Release Engineering 06 Aug '15

06 Aug '15

#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

1 11

#6203: f22-kde koji target
by Fedora Release Engineering 01 Aug '15

01 Aug '15

#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

1 1

[distgit] Moving to sha512, next step
by Mathieu Bridon 13 Jul '15

13 Jul '15

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

2 2

#6183: RPMs from rhel-7-workstation-rpms not mentioned in pkg_el7.json
by Fedora Release Engineering 11 Jul '15

11 Jul '15

#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

1 2

#6204: Please un-retire yaws
by Fedora Release Engineering 11 Jul '15

11 Jul '15

#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

1 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

rel-eng June 2015