rel-eng February 2017

rel-eng@lists.fedoraproject.org

13 participants
201 discussions

[releng] PR #6613 `Script to delete the nightly AMIs periodically`
by Sayan Chowdhury 08 Aug '17

08 Aug '17

sayanchowdhury opened a new pull-request against the project: `releng` that you are following: `` Script to delete the nightly AMIs periodically `` To reply, visit the link below or just reply to this email https://pagure.io/releng/pull-request/6613

4 6

[releng] Issue #6617 `consider cron script for bodhi updates pushes`
by Kevin Fenzi 08 Jun '17

08 Jun '17

kevin reported a new issue against the project: `releng` that you are following: `` Right now we have a list of releng folks that trade off weekly handling bodhi updates pushes. Because all these folks are in different locations and have different workdays and business, updates pushes happen as they are able throughout the day. Additionally some folks are able to push on weekends and holidays and others are not. Since we no longer need a human release engineer to sign packages before pushing updates, we should consider moving this to just a cron script that runs at the same time every day. This would have the advantage of making the pushes much more predictable and would also save time of busy release engineers. The script would need to have a bit of error handling and check for existing lock files and error out if any exist. It would also need to be adjustable during freezes to not push the stable updates for the frozen release. Any issues or problems would need to follow a process of filing a ticket on the issue and all release engineers communicating on that ticket so no one is duplicating efforts. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/6617

4 5

[releng] Issue #6645 `Make sure OSTree repos are sync'ed correctly after the masher completes`
by Jonathan Lebon 06 Jun '17

06 Jun '17

jlebon reported a new issue against the project: `releng` that you are following: `` We have internal testers which essentially check for new commits by polling the `fedora-atomic/25/x86_64/updates/docker-host` ref on https://kojipkgs.fedoraproject.org/atomic/25. When the ref changes, a new test is triggered. We've been seeing failures in which the ref gets updated, but the commit object to which the ref points to is not yet in the repo. We need to make sure that all the refs are being updated safely: first objects, then refs. There is a more complete [rsync-repos](https://github.com/ostreedev/ostree-releng-scripts/blob/master… script that knows how to safely do this. For the updates ref in specific, judging from the masher code, it seems like we're operating on the live repo and then "waiting" for it sync out? https://github.com/fedora-infra/bodhi/blob/1a2871520d719c44f5cab37b2a555474… https://github.com/fedora-infra/bodhi/blob/1a2871520d719c44f5cab37b2a555474… What kind of lag are we talking about? 10m? 30m? Is there any way to know when *all* the files have been synced out? We might need to change this so that we compose on a *copy* of the repo, and then e.g. use the rsync script above to update the real repo. But this presumes that the order in which we rsync to the mount reflects the order in which it hits the public, which may not be true it seems? `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/6645

6 9

[releng] Issue #6599 `Koji build failed without a reason`
by Pagure 06 Jun '17

06 Jun '17

tpopela reported a new issue against the project: `releng` that you are following: `` Hi, the build https://koji.fedoraproject.org/koji/taskinfo?taskID=17391659 of webkitgtk4 failed without a reason on armv7hl and arm64. From the build logs it looks that it was still compiling. There is one error mentioned in notification: <Fault 1: "<class 'pg.OperationalError'>: can't commit"> Here is some log from IRC with Dennis: <tpopela> Hi everyone, can someone explain me why https://koji.fedoraproject.org/koji/taskinfo?taskID=17391659 failed? Is there now some time limit when the compilation have to succeed (if so, it's not enough for WebKitGTK+ ;)) <dgilmore> tpopela: there is a timeout of 48 hours <tpopela> dgilmore, I know about that one :) but from the logs it looks like the task stopped without a reason.. <dgilmore> tpopela: I suspect it was killed for using too much memory <dgilmore> it looks like it was linking on armv7hl <tpopela> dgilmore, no it was building.. <dgilmore> though dmesg does not show that <dgilmore> ps axf <dgilmore> gahh <dgilmore> 2017-01-23 17:23:14,950 [INFO] koji.TaskManager: Task 17391684 (pid 9103) exited with status 0 <dgilmore> 2017-01-23 17:23:15,157 [INFO] koji.TaskManager: Expiring subsession 26602149 (task 17391684) <tpopela> dgilmore, what does that mean? That we have no clue? :) <dgilmore> tpopela: that mock said it finished fine :( <tpopela> dgilmore, hmm let me start a new build and we will see if it was some hiccup.. <dgilmore> thats my best suggestion <dgilmore> the failure in koji is <class 'pg.OperationalError'>: can't commit <dgilmore> which I think is because there was no rpms <dgilmore> but the mock_output.log agrees the build completed okay <dgilmore> which is clearly did not <dgilmore> actually it says that the build started and nothing more <tpopela> dgilmore, I will create a bug on pagure and maybe someone will chime in with some idea.. <dgilmore> tpopela: its either rpmbuild or mock that failed <dgilmore> I suspect mock `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/6599

2 1

[releng] Issue #6603 `Enable rhel-kvm-rpms on EPEL7 aarch64 buildroots`
by Pagure 11 May '17

11 May '17

yselkowitz reported a new issue against the project: `releng` that you are following: `` The virtualization packages for RHEL Server for ARM (aarch64) have been shipped in a separate repository, rhel-kvm-rpms. Please enable this repo on the EPEL7 aarch64 buildroots so that EPEL7 packages which depend on libvirt etc. can be built for aarch64. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/6603

2 3

[releng] Issue #6657 `enable epel7-kde koji target`
by Rex Dieter 25 Apr '17

25 Apr '17

rdieter reported a new issue against the project: `releng` that you are following: `` Want to start work on new kde frameworks release for epel7, which would be greatly simplified using a dedicated koji target (instead of doing 10's of manual overrides). Thanks. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/6657

3 9

[releng] Issue #6609 `Please ship new openh264 builds to cisco`
by Pagure 25 Mar '17

25 Mar '17

kalev reported a new issue against the project: `releng` that you are following: `` openh264-1.6.0-1.fc24 openh264-1.6.0-4.fc25 openh264-1.6.0-4.fc26 Thanks, Kalev `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/6609

3 2

[releng] Issue #6653 `Aarch64 build failure for package "root"`
by Mattias Ellert 17 Mar '17

17 Mar '17

ellert reported a new issue against the project: `releng` that you are following: `` I don't really know where to report this, since I have difficulty understanding what the underlying cause is. I am trying to get one of my packages that failed the F26 rebuild to compile. There where a few minor issues like missing headers and similar, and I now have a version that builds on all architectures except aarch64. The point where the package build fails is not during compilation, but when the build tries to execute the newly built software, which results in a segfault. I am not sure what would case this. There is a new compiler version and a new glibc, there are changes to the default compiler flags and a lot of other things that could make a difference. And I have no way to debug this since I don't have access to an aarch64 system. What I find really confusing is that if I try to build on EPEL 7 I see the same failure as on rawhide for the aarch64 build. This is confusing since the previous EPEL 7 build succeeded. And in this case the new build uses the same gcc, the same glibc and the same kernel-headers as the previous successful build. So I really see no reason for it to fail. I can not see anything that changed between the builds that would cause the previously working build to now fail in the EPEL 7 case. And since the failure in the rawhide build is the same my guess is that the cause is the same. Previous successful F26 build (23 January) root-6.08.04-1.fc26 (including successful aarch64 build) https://koji.fedoraproject.org/koji/buildinfo?buildID=835310 Previous successful EPEL 7 build (15 January) root-6.08.04-1.el7 (including successful aarch64 build) https://koji.fedoraproject.org/koji/buildinfo?buildID=833913 F26 scratch build (21 February) Fails for aarch64 https://koji.fedoraproject.org/koji/taskinfo?taskID=17975998 EPEL 7 scratch build (21 February) Fails for aarch64 https://koji.fedoraproject.org/koji/taskinfo?taskID=17972237 That the EPEL 7 build now fails does not make sense to me. And while the rawhide build could possibly fail for a number of different reasons, the failure is the same as in the EPEL 7 build and therefore possibly due to the same issue. Has anything changed in koji or the aarch64 build servers since the successful builds that could explain this? `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/6653

3 7

[releng] Issue #6619 `f26: changes for container minimal image`
by Dusty Mabe 13 Mar '17

13 Mar '17

dustymabe reported a new issue against the project: `releng` that you are following: `` Description of "change" is [here](https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproje… If this is approved we'd like to create this image at the same time we produce the other docker base image and also deliver it alongside the other docker base image. If this is not acceptable we can discuss alternatives. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/6619

3 2

[releng] Issue #6667 `fedora 25 llvm side tag request`
by Dave Airlie 08 Mar '17

08 Mar '17

airlied reported a new issue against the project: `releng` that you are following: `` Please create f25-llvm for llvm 3.9 work. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/6667

2 2

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

rel-eng February 2017