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
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
smani reported a new issue against the project: `releng` that you are following:
``
On F27 the current version of apitrace is apitrace-7.1-7.fc27.
On F27 x86_64 however,
# dnf install --refresh apitrace-libs.i686
currently gives you apitrace-libs-7.1-7.fc27.i686 (note: -7 instead of -9). On the other hand,
# dnf install --refresh apitrace-libs
gives you apitrace-libs-7.1-9.fc27.x86_64 as expected.
apitrace-libs is multilib whitelisted, but appears to be out of sync.
See also #1541099.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7354
langdon reported a new issue against the project: `releng` that you are following:
``
Once [#7227](https://pagure.io/releng/issue/7227) is complete, I wanted to confirm that:
* We should continue to make PRs against [variants-modular.xml](https://pagure.io/pungi-fedora/blob/master/f/variants-modular.xml) and file tickets here to get new modules added to the compose.
* Should we file tickets here or use some other method to get changes to fedora-release* rpms? Specifically, we will need to include a system profile ([for example](https://github.com/sgallagher/semimodular_poc/blob/master/semimodu…) and modify it as modules are added.
/cc @sgallagh @psabata
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7316
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