[releng] Issue #6997: Dependency issue in repository "build" for EPEL 7 for
aarch64
by Robert Scheck
robert reported a new issue against the project: `releng` that you are following:
``
Builds for EPEL 7 for aarch64 are currently failing due to a dependency issue that should be satisfied by the "build" repository (RHEL 7):
```
DEBUG util.py:439: --> intltool-0.50.2-7.el7.noarch
DEBUG util.py:439: --> gettext-0.19.8.1-2.el7.aarch64
DEBUG util.py:439: --> 1:doxygen-1.8.5-3.el7.aarch64
DEBUG util.py:439: --> graphviz-2.30.1-19.el7.aarch64
DEBUG util.py:439: --> autoconf-2.69-11.el7.noarch
DEBUG util.py:439: --> automake-1.13.4-3.el7.noarch
DEBUG util.py:439: --> libtool-2.4.2-22.el7_3.aarch64
DEBUG util.py:439: --> Already installed : 1:pkgconfig-0.27.1-4.el7.aarch64
DEBUG util.py:439: Error: Package: gettext-devel-0.19.8.1-2.el7.aarch64 (build)
DEBUG util.py:439: Requires: git
DEBUG util.py:439: You could try using --skip-broken to work around the problem
DEBUG util.py:439: You could try running: rpm -Va --nofiles --nodigest
DEBUG util.py:577: Child return code was: 1
DEBUG util.py:188: kill orphans
```
Specific example: https://koji.fedoraproject.org/koji/taskinfo?taskID=21446796
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/6997
5 years, 6 months
[releng] Issue #6984: create a unified repo for fedora 27
by Dusty Mabe
dustymabe reported a new issue against the project: `releng` that you are following:
``
Within the atomic working group we believe there are benefits to having a unified ostree repository (see [discussion](https://pagure.io/atomic-wg/issue/231#comment-432157)). Since we have not yet created an ostree repo for f27 I think now would be a good time for us to create the unified repo and let f27 publish into it. Then we move rawhide over to use that repo after we verify it is working.
I propose the repo go under `https://kojipkgs.fedoraproject.org/atomic/host/`. This would allow for us to also have another unified repo `https://kojipkgs.fedoraproject.org/atomic/workstation/` as well.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/6984
5 years, 6 months
[releng] Issue #6999: A static index for registry.fedoraproject.org
[placeholder]
by Owen Taylor
otaylor reported a new issue against the project: `releng` that you are following:
``
In order for GNOME Software to discover what Flatpaks are available and offer them to users for installation, it needs to be able to obtain:
- A list of repositories in the registry with selected metadata from OCI annotations such as installed size.
- Appstream data for the repositories in the registry to obtain titles, descriptions, icons, and so forth.
The idea is to generate a static file - as compared to a query api, this is more efficient for server load, and clients will typically need all of the information upfront. Static file generation could be done simply from a cron job, or using docker registry webhook notifications (https://docs.docker.com/registry/notifications/) to get faster and more efficient updates.
The Cockpit project has similar needs, and we are coordinating to figure out a common solution.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/6999
5 years, 6 months