5 p.m.
Hey,
when RHEL 7.7 will be released, the following new components/packages will be
provided (assuming from 7.7 beta):
python3 - the Python 3.6 package
================================
This new RHEL7 component builds several subpackages, all obsoleting the
subpackages of epel7 python36 package.
We will simply retire python36 from epel7.
python-rpm-macros
=================
This new RHEL7 component is a drop-in replacement of python-rpm-macros from
epel7, we will simply retire the package. python-epel-rpm-macros already provide
the necessary macros for python34 in epel7.
python3-setuptools
==================
This new RHEL7 component produces the python3-setuptools package that obsoletes
the python36-setuptools package (built from the python3-setuptools epel7 component).
We cannot simply retire python3-setuptools from epel7, as it also builds
python34-setuptools in epel7 and there is no replacement for that in RHEL7.
Easiest thing would be to stop building python36-setuptools and only keep
python34-setuptools in epel7, however IIRC we cannot have the same component
name as in RHEL. If that is indeed the case, python3-setuptools needs to be
retired and a new python34-setuptools component needs to be created in epel7. Is
my assumption correct?
python-pip
==========
This new RHEL7 component produces the python3-pip package that obsoletes the
python36-pip package (built from the python-pip epel7 component).
The python-pip epel7 component also produces python34-pip and python2-pip
(neither available in RHEL 7.7).
If my previous assumption about components with RHEL names is correct, we need 1
or 2 new components for python34-pip and python2-pip - either we have each in a
separate component or we create a new component that builds both (called
python-pip-epel maybe?).
python-wheel
============
This new RHEL7 component produces the python3-wheel package.
The python-wheel epel7 component produced python-wheel package (Python 2).
The epel7 package was adapted to produce python2-wheel and python36-wheel,
however there was no successful build of this in epel7.
If my previous assumption about components with RHEL names is correct,
we need to add a new python2-wheel component to epel7.
------------
Are my assumptions correct?
If we indeed need new packages/components, I can help to create them, but I do
not intent to maintain them. Any takers?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
11:30 a.m.
>>>> "MH" == Miro Hrončok
<mhroncok(a)redhat.com> writes:
MH> Are my assumptions correct?
Yes, unless some major changes happened of which I was not aware, you
cannot have any package name in EPEL7 (including a source package) which
duplicates a package name in RHEL7 _on a particular architecture_.
(There are limited-arch packages as described at
https://fedoraproject.org/wiki/EPEL:Packaging#Limited_Arch_Packages).
In the cases you mention, I do believe you would need new source package
repositories to avoid the conflict. Note that creating these does not
require a package review as long as they are named properly.
- J<
6:33 a.m.
New subject: Python 3 packages to be removed form EPEL 7 (provided by RHEL 7)
On 17. 07. 19 0:00, Miro Hrončok wrote:
...we need 1 or 2 new components for python34-pip and python2-pip -
either
we have each in a separate component or we create a new component that
builds both (called python-pip-epel maybe?).
What is the advice here? If I want it to be just one package, what shall be its
name?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
7:46 a.m.
New subject: Python 3 packages to be removed form EPEL 7 (provided by RHEL 7)
On Thu, 25 Jul 2019 at 08:21, Miro Hrončok <mhroncok(a)redhat.com> wrote:
On 17. 07. 19 0:00, Miro Hrončok wrote:
> ...we need 1 or 2 new components for python34-pip and python2-pip -
either
> we have each in a separate component or we create a new component that
> builds both (called python-pip-epel maybe?).
What is the advice here? If I want it to be just one package, what shall
be its
name?
Sorry, I completely missed that there were points you needed answers on.
Are there any others in the proposal we need to focus on?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
epel-devel mailing list -- epel-devel(a)lists.fedoraproject.org
To unsubscribe send an email to epel-devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproj...
--
Stephen J Smoogen.
7:51 a.m.
New subject: Python 3 packages to be removed form EPEL 7 (provided by RHEL 7)
On Thu, 25 Jul 2019 at 08:46, Stephen John Smoogen <smooge(a)gmail.com> wrote:
On Thu, 25 Jul 2019 at 08:21, Miro Hrončok <mhroncok(a)redhat.com> wrote:
> On 17. 07. 19 0:00, Miro Hrončok wrote:
> > ...we need 1 or 2 new components for python34-pip and python2-pip -
> either
> > we have each in a separate component or we create a new component that
> > builds both (called python-pip-epel maybe?).
>
> What is the advice here? If I want it to be just one package, what shall
> be its
> name?
>
>
Sorry, I completely missed that there were points you needed answers on.
Are there any others in the proposal we need to focus on?
And there are clearly multiple based around this one:
however IIRC we cannot have the same component name as in RHEL. If that is
indeed the case, python3-setuptools needs to be
retired and a new python34-setuptools component needs to be created in
epel7. Is my assumption correct?
Yes your assumption is correct. Koji uses src.rpm names to determine what
it pulls into a buildroot. That means that the python34 items need to have
non-conflicting names with the python3 ones shipped by upstream.. or we
will just start building with python34 or worse.
Would it make sense to just retire python34 completely from EPEL at the 7.7
release date?
--
Stephen J Smoogen.
--
Stephen J Smoogen.
8:30 a.m.
New subject: Python 3 packages to be removed form EPEL 7 (provided by RHEL 7)
On 25. 07. 19 14:51, Stephen John Smoogen wrote:
Yes your assumption is correct. Koji uses src.rpm names to determine
what it
pulls into a buildroot. That means that the python34 items need to have
non-conflicting names with the python3 ones shipped by upstream.. or we will
just start building with python34 or worse.
I've already prepared python34-setuptools:
https://src.fedoraproject.org/rpms/python3-setuptools/pull-request/4
https://bugzilla.redhat.com/show_bug.cgi?id=1733190
And python2-wheel:
https://src.fedoraproject.org/rpms/python-wheel/pull-request/10
https://bugzilla.redhat.com/show_bug.cgi?id=1733193
I'm waiting for the name suggestion for python{2,34}-pip.
Would it make sense to just retire python34 completely from EPEL at
the 7.7
release date?
Python 3.4 is upstream unsupported, so getting rid of it sooner than later is
probably a good idea. However, I suggest to keep it around until EL6 is EOL.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
6:17 a.m.
New subject: Python 3 packages to be removed form EPEL 7 (provided by RHEL 7)
On 25. 07. 19 15:30, Miro Hrončok wrote:
I'm waiting for the name suggestion for python{2,34}-pip.
Is python-pip-epel fine? Or should it be 2 source RPMs?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
6:17 a.m.
New subject: Python 3 packages to be removed form EPEL 7 (provided by RHEL 7)
On 29. 07. 19 13:17, Miro Hrončok wrote:
On 25. 07. 19 15:30, Miro Hrončok wrote:
> I'm waiting for the name suggestion for python{2,34}-pip.
Is python-pip-epel fine? Or should it be 2 source RPMs?
I went with python-pip-epel, since nobody seems to mind that one:
https://bugzilla.redhat.com/show_bug.cgi?id=1737028
https://src.fedoraproject.org/rpms/python-pip/pull-request/39
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
8:09 a.m.
New subject: Python 3 packages to be removed form EPEL 7 (provided by RHEL 7)
On Tue, Jul 16, 2019, 3:48 PM Miro Hrončok <mhroncok(a)redhat.com> wrote:
Hey,
when RHEL 7.7 will be released, the following new components/packages will
be
provided (assuming from 7.7 beta):
python3 - the Python 3.6 package
================================
This new RHEL7 component builds several subpackages, all obsoleting the
subpackages of epel7 python36 package.
We will simply retire python36 from epel7.
python-rpm-macros
=================
This new RHEL7 component is a drop-in replacement of python-rpm-macros
from
epel7, we will simply retire the package. python-epel-rpm-macros already
provide
the necessary macros for python34 in epel7.
python3-setuptools
==================
This new RHEL7 component produces the python3-setuptools package that
obsoletes
the python36-setuptools package (built from the python3-setuptools epel7
component).
We cannot simply retire python3-setuptools from epel7, as it also builds
python34-setuptools in epel7 and there is no replacement for that in RHEL7.
Easiest thing would be to stop building python36-setuptools and only keep
python34-setuptools in epel7, however IIRC we cannot have the same
component
name as in RHEL. If that is indeed the case, python3-setuptools needs to
be
retired and a new python34-setuptools component needs to be created in
epel7. Is
my assumption correct?
python-pip
==========
This new RHEL7 component produces the python3-pip package that obsoletes
the
python36-pip package (built from the python-pip epel7 component).
The python-pip epel7 component also produces python34-pip and python2-pip
(neither available in RHEL 7.7).
If my previous assumption about components with RHEL names is correct, we
need 1
or 2 new components for python34-pip and python2-pip - either we have each
in a
separate component or we create a new component that builds both (called
python-pip-epel maybe?).
python-wheel
============
This new RHEL7 component produces the python3-wheel package.
The python-wheel epel7 component produced python-wheel package (Python 2).
The epel7 package was adapted to produce python2-wheel and python36-wheel,
however there was no successful build of this in epel7.
If my previous assumption about components with RHEL names is correct,
we need to add a new python2-wheel component to epel7.
------------
Are my assumptions correct?
If we indeed need new packages/components, I can help to create them, but
I do
not intent to maintain them. Any takers?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
epel-devel mailing list -- epel-devel(a)lists.fedoraproject.org
To unsubscribe send an email to epel-devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproj...
9:27 a.m.
New subject: Python 3 packages to be removed form EPEL 7 (provided by RHEL 7)
On 17. 07. 19 0:00, Miro Hrončok wrote:
Hey,
when RHEL 7.7 will be released, the following new components/packages will be
provided (assuming from 7.7 beta):
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-31bd12e515
Please somebody do a sanity check, so I can retire python-pip,
python3-setuptools and python-wheel.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
9:49 a.m.
New subject: Python 3 packages to be removed form EPEL 7 (provided by RHEL 7)
I have tested python2-wheel and it worked. Looking to see what needs to be
done for th eohters.
On Fri, 9 Aug 2019 at 10:27, Miro Hrončok <mhroncok(a)redhat.com> wrote:
On 17. 07. 19 0:00, Miro Hrončok wrote:
> Hey,
>
> when RHEL 7.7 will be released, the following new components/packages
will be
> provided (assuming from 7.7 beta):
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-31bd12e515
Please somebody do a sanity check, so I can retire python-pip,
python3-setuptools and python-wheel.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
epel-devel mailing list -- epel-devel(a)lists.fedoraproject.org
To unsubscribe send an email to epel-devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproj...
--
Stephen J Smoogen.
10:30 a.m.
New subject: Python 3 packages to be removed form EPEL 7 (provided by RHEL 7)
On 09. 08. 19 16:49, Stephen John Smoogen wrote:
I have tested python2-wheel and it worked. Looking to see what needs to be done
for th eohters.
Thanks. The update is for all 3 of them.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
10:38 a.m.
New subject: Python 3 packages to be removed form EPEL 7 (provided by RHEL 7)
I tested all three and gave karma.
On Fri, 9 Aug 2019 at 11:32, Miro Hrončok <mhroncok(a)redhat.com> wrote:
On 09. 08. 19 16:49, Stephen John Smoogen wrote:
>
> I have tested python2-wheel and it worked. Looking to see what needs to
be done
> for th eohters.
Thanks. The update is for all 3 of them.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
epel-devel mailing list -- epel-devel(a)lists.fedoraproject.org
To unsubscribe send an email to epel-devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproj...
--
Stephen J Smoogen.
10:39 a.m.
New subject: Python 3 packages to be removed form EPEL 7 (provided by RHEL 7)
On 09. 08. 19 17:38, Stephen John Smoogen wrote:
I tested all three and gave karma.
Thanks. I'll wait for the push and retire the old packages.
I hope everything will work as expected.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
1:41 p.m.
New subject: Python 3 packages to be removed form EPEL 7 (provided by RHEL 7)
On Fri, 9 Aug 2019 17:39:45 +0200
Miro Hrončok <mhroncok(a)redhat.com> wrote:
On 09. 08. 19 17:38, Stephen John Smoogen wrote:
>
>
> I tested all three and gave karma.
Thanks. I'll wait for the push and retire the old packages.
I hope everything will work as expected.
I noticed a issue, python-pip-epel can't be build on up to date 7.7
system because python3_other srpm related macros are not provided by
any package. I guess python-epel-rpm-macros package should provide
python3-other-srpm-macros for python34 related bits. And these two new
packages python3-other-srpm-macros and python3-other-rpm-macros should
be added as dependency to epel-rpm-macros.
Issue caused by missing packages is %python3_other_pkgversion is unset,
in mock log:
DEBUG util.py:587: Error: No Package found for
python%{python3_other_pkgversion}-devel
DEBUG util.py:587: Error: No
Package found for python%{python3_other_pkgversion}-setuptools
--
Tuomo Soini <tis(a)foobar.fi>
Foobar Linux services
+358 40 5240030
Foobar Oy <https://foobar.fi/>
3:26 p.m.
New subject: Python 3 packages to be removed form EPEL 7 (provided by RHEL 7)
On 11. 08. 19 20:41, Tuomo Soini wrote:
On Fri, 9 Aug 2019 17:39:45 +0200
Miro Hrončok <mhroncok(a)redhat.com> wrote:
> On 09. 08. 19 17:38, Stephen John Smoogen wrote:
>>
>>
>> I tested all three and gave karma.
>
> Thanks. I'll wait for the push and retire the old packages.
>
> I hope everything will work as expected.
>
I noticed a issue, python-pip-epel can't be build on up to date 7.7
system because python3_other srpm related macros are not provided by
any package. I guess python-epel-rpm-macros package should provide
python3-other-srpm-macros for python34 related bits. And these two new
packages python3-other-srpm-macros and python3-other-rpm-macros should
be added as dependency to epel-rpm-macros.
There is python-epel-rpm-macros source package in EPEL now.
It builds the python3-other-rpm-macros package.
python34-devel requires python3-other-rpm-macros.
epel-rpm-macros requires python-srpm-macros.
python-srpm-macros form RHEL 7.7+ indeed don't have this bit:
%python3_other_pkgversion 34
I believe the easiest fix is to define that directly in epel-rpm-macros:
https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/5
Thanks for the report!
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
1:14 a.m.
New subject: Python 3 packages to be removed form EPEL 7 (provided by RHEL 7)
On Sun, 11 Aug 2019 22:26:45 +0200
Miro Hrončok <mhroncok(a)redhat.com> wrote:
%python3_other_pkgversion 34
I believe the easiest fix is to define that directly in
epel-rpm-macros:
https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/5
Correct. That fixes this issue but not the huge issue we have now.
Thanks for the report!
I agree. But we have much bigger problem with epel python naming.
python3_other is now defined to 3 in rhel7.7.
Because epel is supposed to add packages to rhel, we have now new
definition which is our master. That means with 7.7 system and mock,
there is no possibility to build python36 packages any more.
Because rhel selected python3 naming when inroduced python3 that gives
epel7 new baseline for naming standard for python3 packages which means
we should now follow that on epel7 post rhel7.7. Before python3 was
added to rhel we could play with python3x naming freely but not any
more.
We have two choises really, this suggestion of mine is based on the
expectation that rhel7 continues to have more python3 packages in
future with naming python3-<modname>.
Let's list some history, please notify if I forgot something important.
python3 packages were introduced to epel with python3x naming
originally, and unlike fedora naming, python3 was replaced on every
package with %python3_pkgversion and related macros. When python 3.6
was introduced to epel7 there was new macro %python3_other_pkgversion
and related to that macros added.
When python 3.4 got EOL, macros were switched and python36 naming was
set for %python3_pkgversion
rhel7.7 introduced python3 with fedora style python3 naming and
%python3_pkgversion set to 3.
Now systems using new python-rpm-macros from rhel7.7 can't any more
build any python3 package because all dependencies switch from
python36-<modname> to python3-<modname> so package builds will fail
inside mock. Because of koji still using old python*rpm-macros this is
not yet visible on fedora build system but I tested and verified this
with mock. Also these new macros cause all new python packages to be
named python3-<modname>.
There are two possibilities how to handle this:
Introduce conflicting %python3_pkgversion (and other related macros)
with 36 and 3.6 etc in them.
This would cause pain in every occasion when there is new python3
package added to rhel7 because rhel7 uses different naming. That
would mean we would need to manually patch dependencies on packages in
rhel7 because we don't have any guarantee that rhel packagers remember
epel when doing rhel packages. So we need to manually change
dependencies to rhel packages to be python3, not
python%{python3_pkgversion}.
My suggestion for this is to do big python3 rebuild again in epel7,
this time with python3_pkgversion from rhel7.7 and move clearly to
rhel7.7 python3 naming and obsolete pythn34 now, people have already
been notified that python34 is end of the life and not supported by
upstream.
Add epel specific python_provide macro which for python3-modname does:
normal provides as it did before.
Provides: python3-<modname> = %{version}-%{release}
Obsoletes: python36-<modname> < %{version}-%{release}
Obsoletes: python34-<modname> < %{version}-%{release}
Remove python3_other from epel7.
Only downside from this is that python3-modname source rpm naming won't
work any more because rpm doesn't allow python3-modname naming in
sub-package. My suggestion for that is to name these epel only
source packages with python3-epel-modname or python3-modname-epel
naming so that they can generate python3-modname.
--
Tuomo Soini <tis(a)foobar.fi>
Foobar Linux services
+358 40 5240030
Foobar Oy <https://foobar.fi/>
3:52 a.m.
New subject: Python 3 packages to be removed form EPEL 7 (provided by RHEL 7)
On 12. 08. 19 8:14, Tuomo Soini wrote:
On Sun, 11 Aug 2019 22:26:45 +0200
Miro Hrončok <mhroncok(a)redhat.com> wrote:
> %python3_other_pkgversion 34
>
> I believe the easiest fix is to define that directly in
> epel-rpm-macros:
>
> https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/5
Correct. That fixes this issue but not the huge issue we have now.
> Thanks for the report!
I agree. But we have much bigger problem with epel python naming.
python3_other is now defined to 3 in rhel7.7.
By what? Do you mean python3_pkgversion? W can override that as well.
Because epel is supposed to add packages to rhel, we have now new
definition which is our master. That means with 7.7 system and mock,
there is no possibility to build python36 packages any more.
Because rhel selected python3 naming when inroduced python3 that gives
epel7 new baseline for naming standard for python3 packages which means
we should now follow that on epel7 post rhel7.7. Before python3 was
added to rhel we could play with python3x naming freely but not any
more.
We have two choises really, this suggestion of mine is based on the
expectation that rhel7 continues to have more python3 packages in
future with naming python3-<modname>.
Let's list some history, please notify if I forgot something important.
python3 packages were introduced to epel with python3x naming
originally, and unlike fedora naming, python3 was replaced on every
package with %python3_pkgversion and related macros. When python 3.6
was introduced to epel7 there was new macro %python3_other_pkgversion
and related to that macros added.
When python 3.4 got EOL, macros were switched and python36 naming was
set for %python3_pkgversion
rhel7.7 introduced python3 with fedora style python3 naming and
%python3_pkgversion set to 3.
Now systems using new python-rpm-macros from rhel7.7 can't any more
build any python3 package because all dependencies switch from
python36-<modname> to python3-<modname> so package builds will fail
inside mock. Because of koji still using old python*rpm-macros this is
not yet visible on fedora build system but I tested and verified this
with mock. Also these new macros cause all new python packages to be
named python3-<modname>.
There are two possibilities how to handle this:
Introduce conflicting %python3_pkgversion (and other related macros)
with 36 and 3.6 etc in them.
Let's do that as a quick hotfix for now decide the rest later.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
4:15 a.m.
New subject: Python 3 packages to be removed form EPEL 7 (provided by RHEL 7)
On 12. 08. 19 10:52, Miro Hrončok wrote:
On 12. 08. 19 8:14, Tuomo Soini wrote:
> On Sun, 11 Aug 2019 22:26:45 +0200
> Miro Hrončok <mhroncok(a)redhat.com> wrote:
>
>> %python3_other_pkgversion 34
>>
>> I believe the easiest fix is to define that directly in
>> epel-rpm-macros:
>>
>> https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/5
>
> Correct. That fixes this issue but not the huge issue we have now.
>
>> Thanks for the report!
>
> I agree. But we have much bigger problem with epel python naming.
>
> python3_other is now defined to 3 in rhel7.7.
By what? Do you mean python3_pkgversion? W can override that as well.
> Because epel is supposed to add packages to rhel, we have now new
> definition which is our master. That means with 7.7 system and mock,
> there is no possibility to build python36 packages any more.
>
> Because rhel selected python3 naming when inroduced python3 that gives
> epel7 new baseline for naming standard for python3 packages which means
> we should now follow that on epel7 post rhel7.7. Before python3 was
> added to rhel we could play with python3x naming freely but not any
> more.
>
> We have two choises really, this suggestion of mine is based on the
> expectation that rhel7 continues to have more python3 packages in
> future with naming python3-<modname>.
>
> Let's list some history, please notify if I forgot something important.
>
> python3 packages were introduced to epel with python3x naming
> originally, and unlike fedora naming, python3 was replaced on every
> package with %python3_pkgversion and related macros. When python 3.6
> was introduced to epel7 there was new macro %python3_other_pkgversion
> and related to that macros added.
>
> When python 3.4 got EOL, macros were switched and python36 naming was
> set for %python3_pkgversion
>
> rhel7.7 introduced python3 with fedora style python3 naming and
> %python3_pkgversion set to 3.
>
> Now systems using new python-rpm-macros from rhel7.7 can't any more
> build any python3 package because all dependencies switch from
> python36-<modname> to python3-<modname> so package builds will fail
> inside mock. Because of koji still using old python*rpm-macros this is
> not yet visible on fedora build system but I tested and verified this
> with mock. Also these new macros cause all new python packages to be
> named python3-<modname>.
>
> There are two possibilities how to handle this:
>
> Introduce conflicting %python3_pkgversion (and other related macros)
> with 36 and 3.6 etc in them.
Let's do that as a quick hotfix for now decide the rest later.
Updated https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/5
Please some EPEL people, review and possibly build soon.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
6:07 a.m.
New subject: Python 3 packages to be removed form EPEL 7 (provided by RHEL 7)
On Mon, 12 Aug 2019 10:52:34 +0200
Miro Hrončok <mhroncok(a)redhat.com> wrote:
> python3_other is now defined to 3 in rhel7.7.
By what? Do you mean python3_pkgversion? W can override that as well.
Sorry. python3_pkgversion.
--
Tuomo Soini <tis(a)foobar.fi>
Foobar Linux services
+358 40 5240030
Foobar Oy <https://foobar.fi/>
1712
days inactive
1739
days old
epel-devel@lists.fedoraproject.org
19 comments
5 participants
participants (5)
-
Jason L Tibbitts III -
Miro Hrončok -
Stephen John Smoogen -
Toshio Kuratomi -
Tuomo Soini