RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1848938 - EL8 build unexpectedly drags Python 3.8 macros
Summary: EL8 build unexpectedly drags Python 3.8 macros
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: python38
Version: 8.2
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Python Maintainers
QA Contact: RHEL CS Apps Subsystem QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-06-19 10:14 UTC by Marc Dequènes (Duck)
Modified: 2020-06-25 10:38 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-06-25 10:38:40 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Marc Dequènes (Duck) 2020-06-19 10:14:47 UTC 
Description of problem:
Build 1487441 for @pizza-cats/mailman3-rpm-repo-api-3.1 on EL8 fails because it tries to use Python 3.8.

It's true since 8.2 it is possible to use 3.8 aside the default 3.6 but it needs to be activated. Here I can see the builder install python38-rpm-macros but the spec file did not request this, only python%{python3_pkgversion}-* BuildRequires, thus only 3.6 build dependencies. The log shows the `python38` module stream is enabled but I think this should be not be the default unless Python 3.8 BuildRequires are detected.

Version-Release number of selected component (if applicable):


How reproducible:
While fixing some warnings I saw this was reproducible but did not attemps on other packages yet.


Actual results:
Build tries to use Python 3.8.

Expected results:
Build should stick to the default EL8 Python version unless BuildRequires contains Python 3.8 build dependencies.

Additional info:
full log: https://download.copr.fedorainfracloud.org/results/@pizza-cats/mailman3-rpm-repo-api-3.1/epel-8-x86_64/01487441-python-pytest-services/builder-live.log.gz
Comment 1 Neal Gompa 2020-06-22 03:52:19 UTC 
This is happening because your build environment doesn't have a newer epel-rpm-macros package. This was fixed in epel-release-8-11, which is available on the mirror network, but apparently not on the mirror your copr build used.
Comment 2 Neal Gompa 2020-06-22 03:53:12 UTC 
Bleck, I mean epel-rpm-macros-8-11, not epel-release-8-11... Clearly it's far too late at night for me to be writing responses. :)
Comment 3 Pavel Raiskup 2020-06-22 05:56:12 UTC 
Hmm.  I thought I already flipped this bug against dnf, perhaps some
mid-air collision rejected my change.  Sorry for the late reply.

Installing:
 python38-rpm-macros       noarch   3.8.0-6.module_el8.2.0+317+61fa6e7d  AppStream  66 k
Enabling module streams:
 python38                  3.8

Is it really OK to enable modules by simply installing python38-rpm-macros
package?
Comment 4 Daniel Mach 2020-06-22 11:25:33 UTC 
Yes, it's expected.
When a stream is default, its packages are available and installing them enables the stream.
python38:3.8 is a default stream on RHEL.

This seems to be a packaging issue in the package you're trying to build,
something related to comment#1
or there could be a problem with python packages sharing the same provides.

Reassigning to python so the devs can check what could be wrong.
Comment 5 Miro Hrončok 2020-06-22 12:03:38 UTC 
If you wish to build Python 3.6 package, buildrequire python36-rpm-macros. 
If you wish to build Python 3.8 package, buildrequire python38-rpm-macros.

EPEL macros already should have a workaround in place that prefers python36-rpm-macros if you have not specified the macros explicitly.

> Is it really OK to enable modules by simply installing python38-rpm-macros package?

Define OK. This is how default modular streams were designed.
Comment 6 Miro Hrončok 2020-06-22 12:06:22 UTC 
The EPEL workaround is https://src.fedoraproject.org/rpms/epel-rpm-macros/c/307b3330c011d723855096ae4c80d715abad481c?branch=epel8 -- it ws built in https://koji.fedoraproject.org/koji/buildinfo?buildID=1525373 bu there is no update. Troy, could you plese ship this?
Comment 7 Troy Dawson 2020-06-22 13:30:13 UTC 
When I built it, bodhi wasn't working with authentication.  It's working now.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-790135c4fa
Comment 8 Miro Hrončok 2020-06-22 15:46:04 UTC 
Thanks, Troy.
Comment 9 Marc Dequènes (Duck) 2020-06-24 10:05:26 UTC 
It went in and it is now working fine, thanks a lot all of you :-).
Comment 10 Miro Hrončok 2020-06-24 10:07:23 UTC 
BTW From my point of view, this is still an usability bug for RHEL 8. It is only fixed in EPEL.
Comment 11 Marc Dequènes (Duck) 2020-06-24 11:28:54 UTC 
Agreed, it should at least be fixed in 8.3.
Comment 12 Troy Dawson 2020-06-24 13:31:47 UTC 
Thanks to everyone for their input in getting this fixed.
I am closing this bug.
Comment 13 Miro Hrončok 2020-06-24 13:35:52 UTC 
(In reply to Miro Hrončok from comment #10)
> BTW From my point of view, this is still an usability bug for RHEL 8. It is
> only fixed in EPEL.
Comment 14 Troy Dawson 2020-06-24 13:44:51 UTC 
Sorry about that.
This has been going on so long, and I have so many other EPEL tickets, I thought this was one of them.
Comment 15 Miro Hrončok 2020-06-24 13:55:55 UTC 
Don't worry about it. Thanks for the EPEL fix!
Comment 16 Miro Hrončok 2020-06-25 10:38:40 UTC 
I stand corrected. The only reason the macros were pulled in originated in EPEL, where this is now fixed. Sorry for the noise.
Note You need to log in before you can comment on or make changes to this bug.