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
till reported a new issue against the project: `releng` that you are following:
``
orphan-all-packages.py only updates pagure, but fedora-scm-requests also contains owners for other branches such as EPEL.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7083
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
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
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
kellin reported a new issue against the project: `releng` that you are following:
``
$ koji taginfo f27
Tag: f27 [417]
Arches: armv7hl i686 x86_64 ppc64 ppc64le aarch64
^PGroups: appliance-build, build, livecd-build, livemedia-build, srpm-build
Required permission: 'admin'
Tag options:
mock.package_manager : 'dnf'
Inheritance:
$ koji taginfo f27-build
Tag: f27-build [425]
Arches: aarch64 armv7hl i686 ppc64 ppc64le s390x x86_64
Groups: appliance-build, build, livecd-build, livemedia-build, srpm-build
Required permission: 'admin'
Tag options:
This tag is a buildroot for one or more targets
Current repo: repo#785431: 2017-09-14 21:09:29.969602
Targets that build from this tag:
f27-candidate
f27-rebuild
f27-binutils-rebuild
f27
Inheritance:
0 .... f27-override [424]
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7031
bowlofeggs reported a new issue against the project: `releng` that you are following:
``
Greetings!
I've discovered that [Bodhi doesn't build in F27](https://koji.fedoraproject.org/koji/taskinfo?taskID=22659036) as of recently, as libtomcrypt doesn't seem to be available in the buildroot:
```
- nothing provides libtomcrypt.so.0()(64bit) needed by python2-crypto-2.6.1-17.fc27.s390x
```
I [reported this](https://bugzilla.redhat.com/show_bug.cgi?id=1505641) to the libtomcrypt maintainer, who pointed out that it seems to be tagged correctly. I then realized that I was able to install it in an f27 container as well:
```
$ sudo docker run --rm registry.fedoraproject.org/fedora:27 dnf install python2-crypto -y
```
Is there maybe something wrong with the f27 buildroot that causes this issue?
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7110
rdieter reported a new issue against the project: `releng` that you are following:
``
Please create a f27-kde koji sidetarget, have a few large batched updates to do (already). No rest for the wicked.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7030
dustymabe reported a new issue against the project: `releng` that you are following:
``
We have just started running bodhi updates via pungi (woo!!). One of the reasons the Atomic team has been helping drive this initiative is so that we can get better versioning of our ostrees output by fedora (via pungi).
When we started doing the runs we added a label to them of the form: `Update-20171025.1312`. Which translates into an ostree version of `27_Update.20171025.1312`. The atomic working group had previously got together and [decided](https://pagure.io/atomic-wg/issue/229) that a versioning scheme like `27.2017025.0` would be what we went with for better versioning for ostrees. This scheme was discussed with releng (including dennis) and also added as an RFE to pungi, which was implemented by @lsedlar in [PR](https://pagure.io/pungi/pull-request/592).
With the updates run we can get the desired version if we provide `--no-label` to pungi instead of actually giving it a label. This warrants the question: "what is the value of the label for an updates run?". Do we need it? What is it used for?
If we don't need it then I'd love to just use `--no-label`. If we do need it then we'll have to implement another smart versioning macro for ostrees in pungi.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7113