[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, 10 months
[releng] Issue #6602 `bodhi masher failed to mash f25-updates-testing`
by Pagure
parasense reported a new issue against the project: `releng` that you are following:
``
Bodhi failed the f25-testing push due to errors around ostree. There appears to be updated ostree in the f25 update push (testing). I'm attaching the log file for your analysis.
/srv/fedora-atomic/logs/25/x86_64/updates-testing/docker-host/f25-updates-testing-170125.0315
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/6602
7 years, 1 month
[releng] Issue #6601 `Migrate the tickets from (old) trac`
by Pagure
praiskup reported a new issue against the project: `releng` that you are following:
``
After quick discussion on #fedora-buildsys, I'm rather requesting here to not forget:
```
<praiskup> Hi all! I'd like to be on https://fedorahosted.org/rel-eng/ticket/5622 CC, is there a way now?
<dgilmore> praiskup: there is no way
<dgilmore> you can make it but they can not be deleted
<praiskup> dgilmore, is this some bug in migration to pagure?
<praiskup> because that ticked filed by vondruch is still valid IMO
* vondruch nods
<dgilmore> praiskup: yes importing of issues from fedorahosted to pagure did not work
<dgilmore> so none of the issues migrated
<praiskup> dgilmore, I guess the migration is still on the plan, right?
<dgilmore> praiskup: not sure, nirik was working on it
<praiskup> I would propose two solutions, either (a) please migrate the tickets or (b) or revert the read-only change on old tracker in the meantime ...
<praiskup> nirik, wdyt ^?
<vondruch> praiskup, nirik: or at least announce that we should migrate by hand
```
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/6601
7 years, 1 month
[releng] Issue #6600 `Mock and sigined rawhides`
by Pagure
msuchy reported a new issue against the project: `releng` that you are following:
``
We have signed rawhides now. Great. So I (as mock maintainer) am going to enable gpgcheck in rawhide configs. But there will be problem around branching.
When we branch F26, you will create new gpg key for F27 and rawhide will be signed by F27 keys. So until people update mock (which may take 2 weeks) on EPEL. They will have invalid GPG key for rawhide and therefore mock rawhide builds will fail for them.
There is one option as you can put in yum/dnf config more than one GPG keys. E.g.:100:
`gpgkey=file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-25-primary,file:///fooo/bar`
But which one as F27 keys does not exists yet. And DNF will complain on nonexistent file (just tested that).
So the question is: what to put in mock config so
1) DNF in mock check gpgkey on rawhide
2) it does not cause problem to users during branching period
3) ideally it does not change rawhide mock config every release (so update does not create .rpmnew files).
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/6600
7 years, 2 months
[releng] Issue #6606 `add Cloud image compose`
by Pagure
ausil reported a new issue against the project: `releng` that you are following:
``
QA for some of their work are regularly building Cloud images. we build f25 but not f24 today as we build them in the atomic compose. Lets setup a separate daily compose for cloud base images and stop making them in the atomic compose
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/6606
7 years, 2 months