[releng] Issue #7097: Automate the process of reviewing and merging PRs on
releng/fedora-scm-requests
by Pierre-YvesChibon
pingou reported a new issue against the project: `releng` that you are following:
``
The https://pagure.io/releng/fedora-scm-requests/ project is used for few things:
- Ask for a new package to be added to the distro
- Ask for a new branch on an existing package
- Tune the anitya integration flag
- Set bugzilla overrides (so EPEL bugs go to a different person than the Fedora ones)
The first two tasks are requested by tickets at: https://pagure.io/releng/fedora-scm-requests/issues and processed by releng using [fedrepo-req]().
The last two tasks are requested by PRs and could be automatically reviewed and merged.
I would like to propose that we do this automation, all it requires is checking that the person opening the ticket has ACLs on the project (up to us if we want to limit this to ``admins`` for example). If these people have ACL on the project, then it's just like on pkgdb before, we let the users configure things the way they want.
I do not think there is a good reason to be blocking any changes the maintainers want to do on their package.
Thoughts?
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7097
4 years, 11 months
[releng] Issue #7079: reset 27 atomic host ostree repo
by Dusty Mabe
dustymabe reported a new issue against the project: `releng` that you are following:
``
We are currently using smart versioning for our ostree repo in Fedora 27 (i.e. using `"version": '!OSTREE_VERSION_FROM_LABEL_DATE_TYPE_RESPIN'` feature of pungi). Since we have not yet completed the work to move bodhi to pungi from mash we need to go back to not smart versioning like we were doing in previous releases for now. I'll open a PR against pungi-fedora for this.
In order to do this we need the repo to be reset. This can be as simple as removing just the refs `fedora/27/${basearch}/atomic-host`. Extra credit would be to also prune the repo so that we drop content we no longer care about.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7079
4 years, 11 months
[releng] Issue #7071: libcrypt-nss-2.26-8.fc27.i686 missing from Fedora 27
x86_64 compose
by Florian Weimer
fweimer reported a new issue against the project: `releng` that you are following:
``
The multlib RPM went missing:
$ rsync rsync://ftp-stud.hs-esslingen.de/fedora/linux/updates/testing/27/x86_64/l/ | grep libcrypt
-rw-r--r-- 74,352 2017/09/15 12:51:44 libcrypt-2.26-8.fc27.i686.rpm
-rw-r--r-- 73,492 2017/09/15 12:53:17 libcrypt-2.26-8.fc27.x86_64.rpm
-rw-r--r-- 66,192 2017/09/15 12:50:54 libcrypt-nss-2.26-8.fc27.x86_64.rpm
This currently breaks updates, see [#1495431](https://bugzilla.redhat.com/show_bug.cgi?id=1495431).
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7071
4 years, 11 months
[releng] Issue #7067: Fix package ownership in koji
by Dennis Gilmore
ausil reported a new issue against the project: `releng` that you are following:
``
in talking to @ralph about why everything in koji is owner by releng, when it should be owned by someone responsible for the package. It was switched to releng due to fetching the information from pagure taking too long.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7067
4 years, 11 months
[releng] Issue #7344: Please generate static deltas for FAW27
by Colin Walters
walters reported a new issue against the project: `releng` that you are following:
``
ostree has had static deltas for years now; it makes us look less than stellar if people aren't getting them. We do this as part of the FAH release process, but at the moment there is no such thing for FAW which just drops out of pungi. Simplest thing is probably to add it to Ansible for now, literally just `ostree --repo=/path/to/repo static-delta generate --if-not-exists fedora/27/x86_64/workstation`. (However, the benefits of deltas will be greatly maximized if we batch updates)
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7344
5 years
[releng] Issue #7405: [s390x] Latest cloud-base and (or) container images
are failing for F28 and rawhide composes
by Sinny Kumari
sinnykumari reported a new issue against the project: `releng` that you are following:
``
By looking into last few nightly composes for container and cloud on s390x, I observed that we never had all of the artifacts built successfully in a single compose.
For example:
* From Fedora-28-20180317.n.0 - cloud-base and container-minimal-base image built successfully. container-base image failed
* From Fedora-28-20180317.n.0 - cloud-base and container-base image built successfully. conatiner-minimal-base image failed.
Similar results from rest of the latest compose.
I did some local run of these images using imagefactory and each time following behavior has been seen:
* kernel.img and initrd files get downloaded, vm gets launched to start install process.
* vm boots and it reaches at
[ OK ] Reached target System Initialization.
[ OK ] Reached target Basic System.
[ 35.891858] dracut-initqueue[817]: RTNETLINK answers: File exists
[ 76.688981] random: crng init done
[ 427.634076] dracut-initqueue[817]: Warning: dracut-initqueue timeout - starting timeout scripts
---
[ 625.922797] dracut-initqueue[817]: Warning: dracut-initqueue timeout - starting timeout scripts
[ 625.923855] dracut-initqueue[817]: Warning: Could not boot.
Starting Dracut Emergency Shell...
Warning: /dev/root does not exist
dracut:/#
and vm install stops here.
Not sure what is the reason of this behavior. Can it be something related to network between s390x machine and koji ?
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7405
5 years