[releng] Issue #6617 `consider cron script for bodhi updates pushes`
by Kevin Fenzi
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
6 years, 3 months
[releng] Issue #6599 `Koji build failed without a reason`
by Pagure
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
6 years, 3 months
[releng] Issue #6653 `Aarch64 build failure for package "root"`
by Mattias Ellert
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
6 years, 6 months