[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, 10 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, 10 months
[releng] Issue #6688 `Enabling Atomic Host composes for ppc64le and aarch64
arches`
by Sinny Kumari
sinnykumari reported a new issue against the project: `releng` that you are following:
``
Right now, Atomic Host composes are created for x86_64 arch. With decreasing gap between x86_64 and other supported arches in Fedora, we (Alternative arches group) are looking towards enabling Atomic Host composes in Fedora for ppc64le and aarch64. We have also discussed with Dusty Mabe from Atomic working group to see the possibility of having Atomic Host on non x86_64 arches and we both groups are positive towards helping and working together to enable it on other arches.
In order to achieve that, it will be great help if rel-eng can enable Atomic Host composes for ppc64le and aarch64 as well which can be non-blocking in the beginning. With composes, it will be easier to test and see current situation of Atomic Host on asked arches and we can start working on fixing encountered problems.
Thanks
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/6688
6 years, 10 months
[releng] Issue #6746: Produce a slimmed-down compose whenever certain
packages appear in an update
by Adam Williamson
adamwill reported a new issue against the project: `releng` that you are following:
``
So yesterday @mkolman pinged and told me a [new anaconda update for Fedora 26](https://bodhi.fedoraproject.org/updates/FEDORA-2017-10db06fadf) was available.
Here's what happens next:
* I manually create a Workstation live image containing that anaconda.
* I manually create a Server or Everything netinst image containing that anaconda.
* I scp these images over to the openQA staging server.
* I manually trigger an openQA test run on those images.
* I manually examine the results and post karma to Bodhi.
This is all very silly and shouldn't happen. What should happen (IMHO) is that, when updates to certain packages appear, some releng bot should automatically produce a slimmed-down compose (maybe just those two images, maybe also a couple others, not sure). Then I could adapt the openQA update testing stuff to wait for the compose to appear and automatically run appropriate tests on it. Then we could all go get a drink.
Can we do this? What bits are needed? A compose profile (like `Fedora`, `Fedora-Atomic`, `Fedora-Cloud` etc.)? A fedmsg consumer to listen for update events and fire off a compose using that profile? Any other bits I'm not aware of?
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/6746
6 years, 11 months
[releng] Issue #6715 `kerberos credentials cache error during f26 nightly
pungi run`
by Dusty Mabe
dustymabe reported a new issue against the project: `releng` that you are following:
``
We keep seeing kerberos failures when running our nightly pungi runs in f26. It doesn't happen all the time but has happened a couple of times in f26 so far. [The log](https://kojipkgs.fedoraproject.org/compose/branched/Fedora-26-201703... from 03/20 ostree tree compose shows the error:
```
COMMAND: koji --profile=compose_koji runroot --new-chroot --use-shell --task-id --channel-override=compose --package=pungi --package=ostree --package=rpm-ostree --mount=/mnt/koji/compose/branched/Fedora-26-20170320.n.0 --mount=/mnt/koji/compose/ostree/26/ f26-build x86_64 'rm -f /var/lib/rpm/__db*; rm -rf /var/cache/yum/*; set -x; pungi-make-ostree tree --repo=/mnt/koji/compose/ostree/26/ --log-dir=/mnt/koji/compose/branched/Fedora-26-20170320.n.0/logs/x86_64/ostree/ostree-3 --treefile=/mnt/koji/compose/branched/Fedora-26-20170320.n.0/work/ostree-3/config_repo/fedora-ostree-workstation.json --extra-config=/mnt/koji/compose/branched/Fedora-26-20170320.n.0/work/ostree-3/extra_config.json'
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Kerberos authentication failed: Internal credentials cache error (-1765328188)
```
@parasense suggested that it's possible the pungi compose took longer than the krb5 ticket lifespan. This run started at `2017-03-20 07:17:28` and the failure happened around `2017-03-20 12:25:57`.
@parasense thinks "we might want keytabs" for this?
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/6715
6 years, 11 months