robert reported a new issue against the project: `releng` that you are following:
``
* Describe the issue
The package `libssh` got part of the `rhel-7-{server,workstation}-extras-rpms` repo, however only for the x86_64 architecture, but not for aarch64, ppc64 and ppc64le. Thus it is currently not possible to build e.g. `tmate` for EPEL 7 on all architectures.
As per https://fedoraproject.org/wiki/EPEL:Packaging#Limited_Arch_Packages, I would like to import the current RHEL source RPM into EPEL 7 with lower ENVRA, but the `epel7` branch of `libssh` is blocked in Git (and likely also in Koji).
```
! [remote rejected] epel7 -> epel7 (hook declined)
```
* When do you need this? (YYYY/MM/DD)
As soon as possible, but not urgent.
* When is this no longer needed or useful? (YYYY/MM/DD)
n/a
* If we cannot complete your request, what is the impact?
n/a
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7846
ralph reported a new issue against the project: `releng` that you are following:
``
See this older thread on the infra list for some context: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedorapr…
We created a tool that will automatically tag *some* module builds into the inheritance hierarchy for the base buildroot. Adopting it in Fedora will provide a way for some rpms to move 100% into modules while still being available at buildtime to other core packages which need them.
@sgallagh and @mizdebsk, can you elaborate?
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7840
las0mbra reported a new issue against the project: `releng` that you are following:
``
* Describe the issue
I'd like to take over the maven package.
* When do you need this? (YYYY/MM/DD)
As soon as possible, before it is retired.
* If we cannot complete your request, what is the impact?
As a Java developer the impact of not having a maven package is huge across the Java ecosystem
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8179
tibbs reported a new issue against the project: `releng` that you are following:
``
* Describe the issue
The mass-rebuild failure script at https://pagure.io/releng/blob/master/f/scripts/find_failures.py which generates https://kojipkgs.fedoraproject.org/mass-rebuild/f29-failures.html makes use of only the first maintainer in the data returned by pagure. So the list misses many maintainers, and this has generated a couple of complaints about it not being easy for some people to find packages they need to look at.
There's a script we use when mailing out notices about package problems and mass package changes which lives at https://pagure.io/fedora-misc-package-utilities/blob/master/f/find-package-…. That script generates two lists: one lists packages with a list of maintainers, the other lists maintainers with a list of packages. We find this to be a pretty useful format.
One other thing from our script which would be useful is that it makes use of the cached owner data provided by pagure (at https://src.fedoraproject.org/extras/pagure_owner_alias.json) instead of making an API call per package. This speeds it up, well, a whole lot. That file is updated hourly.
* When do you need this?
Would be nice to have it before the next mass rebuild, though I guess if we can change it before this one is complete then why not.
* When is this no longer needed or useful?
I guess it would always be nice to have this.
* If we cannot complete your request, what is the impact?
Probably just more complaints about packagers not seeing their names in the list when packages they maintain fail to build.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7635
sgallagh reported a new issue against the project: `releng` that you are following:
``
I'm going to be updating Node.js to 10.x in Fedora 29 which may (unclear yet) require a side-tag to rebuild the native packages. We need a review by rel-eng as part of the Change Process.
CC @jkurik
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7537
fweimer reported a new issue against the project: `releng` that you are following:
``
https://fedoraproject.org/wiki/Changes/i686_Is_For_x86-64
The only releng concern is that we should have a mass rebuild for this (if only as the last opportunity to back it out again).
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7543
churchyard reported a new issue against the project: `releng` that you are following:
``
Please first read trough https://pagure.io/packaging-committee/issue/691
We have been approached by this question:
1. I have an noarch package `foo`
2. it has (implicitly noarch) subpackage `foo-extra`, it has a runtime dependency on `extra` package (that is not available on `xyz` arch)
How do I proceed to exclude the `foo-extra` subpackage from being build/available on the `xyz` arch?
Do I need to switch both the main package and the subpackage to be arched?
In FPC, we have some _ideas_ about how it _should_ work, however, we don't know how it actually is implemented.
Thanks
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7553