I see the update in koji/bodhi, thanks for doing that so quickly.
-Erinn
On 3/31/20 4:06 PM, Miro Hrončok wrote:
On 31. 03. 20 23:40, Erinn Looney-Triggs wrote:
Interestingly... no it did not and the reason is I built against
rhel-7-x86_64 in mock not epel-7-x86_64. I believe there is a macro
On 3/31/20 3:23 PM, Miro Hrončok wrote:
%{python3} = python3
%{python3} = /usr/bin/python3
At least in Fedora. In EPEL, most likely as well.
See https://bugzilla.redhat.com/show_bug.cgi?id=1812665
There's a bug in the macros.
But that bug has nothing to do with either %python3 or
Thanks for the quick reply. Disappointing, but it happens.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
I am trying to build a package for RHEL 7 and RHEL 8 that depends on an EPEL
(for RHEL 7) package python36-dbus the requires section goes like so:
Requires: %{python3}
Requires: %{python3}-dbus
This puts in a requirement for python3-dbus for RHEL 7 which doesn't exist, the
package is actually
There are a number of packages in EPEL 6 and 7 that conflict with
packages provided by either RH Satellite or the katello-agent.
A quick run through for an up to date (6.1.9) install of satellite on
RHEL 7:
bouncycastle.noarch 1.50-1.el7 epel
createrepo_c.x86_64
There are a number of packages in EPEL 6 and 7 that conflict with
packages provided by either RH Satellite or the katello-agent.
A quick run through for an up to date (6.1.9) install of satellite on
RHEL 7:
bouncycastle.noarch 1.50-1.el7 epel
createrepo_c.x86_64
