Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.

Bug 1734775

Summary: python-dateutil fails to build with in Fedora 31 (rawhide)
Product: [Fedora] Fedora Reporter: Miro Hrončok <mhroncok>
Component: python-dateutilAssignee: Haïkel Guémar <karlthered>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: rawhideCC: gwync, igor.raits, jspaleta, karlthered, pj.pandit, pviktori, python-sig, steve.traylen, tomspur
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-08-12 23:29:54 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1700317, 1686977, 1732841    

Description Miro Hrončok 2019-07-31 12:10:17 UTC 
python-dateutil fails to build with Python 3.8.0b3.

+ /usr/bin/python3 -m pytest
error: Bad exit status from /var/tmp/rpm-tmp.pPDDgv (%check)
============================= test session starts ==============================
platform linux -- Python 3.8.0b3, pytest-4.6.4, py-1.8.0, pluggy-0.12.0
hypothesis profile 'default' -> database=DirectoryBasedExampleDatabase('/builddir/build/BUILD/python-dateutil-2.8.0/.hypothesis/examples')
rootdir: /builddir/build/BUILD/python-dateutil-2.8.0, inifile: setup.cfg
plugins: hypothesis-4.23.8
collected 1043 items / 6 errors / 1037 selected
INTERNALERROR> Traceback (most recent call last):
INTERNALERROR>   File "/usr/lib/python3.8/site-packages/_pytest/main.py", line 206, in wrap_session
INTERNALERROR>     session.exitstatus = doit(config, session) or 0
INTERNALERROR>   File "/usr/lib/python3.8/site-packages/_pytest/main.py", line 249, in _main
INTERNALERROR>     config.hook.pytest_collection(session=session)
INTERNALERROR>   File "/usr/lib/python3.8/site-packages/pluggy/hooks.py", line 289, in __call__
INTERNALERROR>     return self._hookexec(self, self.get_hookimpls(), kwargs)
INTERNALERROR>   File "/usr/lib/python3.8/site-packages/pluggy/manager.py", line 91, in _hookexec
INTERNALERROR>     return self._inner_hookexec(hook, methods, kwargs)
INTERNALERROR>   File "/usr/lib/python3.8/site-packages/pluggy/manager.py", line 82, in <lambda>
INTERNALERROR>     self._inner_hookexec = lambda hook, methods, kwargs: hook.multicall(
INTERNALERROR>   File "/usr/lib/python3.8/site-packages/pluggy/callers.py", line 208, in _multicall
INTERNALERROR>     return outcome.get_result()
INTERNALERROR>   File "/usr/lib/python3.8/site-packages/pluggy/callers.py", line 80, in get_result
INTERNALERROR>     raise ex[1].with_traceback(ex[2])
INTERNALERROR>   File "/usr/lib/python3.8/site-packages/pluggy/callers.py", line 187, in _multicall
INTERNALERROR>     res = hook_impl.function(*args)
INTERNALERROR>   File "/usr/lib/python3.8/site-packages/_pytest/main.py", line 259, in pytest_collection
INTERNALERROR>     return session.perform_collect()
INTERNALERROR>   File "/usr/lib/python3.8/site-packages/_pytest/main.py", line 497, in perform_collect
INTERNALERROR>     hook.pytest_collection_modifyitems(
INTERNALERROR>   File "/usr/lib/python3.8/site-packages/pluggy/hooks.py", line 289, in __call__
INTERNALERROR>     return self._hookexec(self, self.get_hookimpls(), kwargs)
INTERNALERROR>   File "/usr/lib/python3.8/site-packages/pluggy/manager.py", line 91, in _hookexec
INTERNALERROR>     return self._inner_hookexec(hook, methods, kwargs)
INTERNALERROR>   File "/usr/lib/python3.8/site-packages/pluggy/manager.py", line 82, in <lambda>
INTERNALERROR>     self._inner_hookexec = lambda hook, methods, kwargs: hook.multicall(
INTERNALERROR>   File "/usr/lib/python3.8/site-packages/pluggy/callers.py", line 208, in _multicall
INTERNALERROR>     return outcome.get_result()
INTERNALERROR>   File "/usr/lib/python3.8/site-packages/pluggy/callers.py", line 80, in get_result
INTERNALERROR>     raise ex[1].with_traceback(ex[2])
INTERNALERROR>   File "/usr/lib/python3.8/site-packages/pluggy/callers.py", line 187, in _multicall
INTERNALERROR>     res = hook_impl.function(*args)
INTERNALERROR>   File "/builddir/build/BUILD/python-dateutil-2.8.0/dateutil/test/conftest.py", line 20, in pytest_collection_modifyitems
INTERNALERROR>     item.add_marker(pytest.mark.no_cover)
INTERNALERROR>   File "/usr/lib/python3.8/site-packages/_pytest/mark/structures.py", line 330, in __getattr__
INTERNALERROR>     warnings.warn(
INTERNALERROR> _pytest.warning_types.PytestUnknownMarkWarning: Unknown pytest.mark.no_cover - is this a typo?  You can register custom marks to avoid this warning - for details, see https://docs.pytest.org/en/latest/mark.html

=========================== 6 error in 0.92 seconds ============================

The failure is unrelated to Python 3.8, but most likely to pytest 4.6.
Here is a Koji rawhide build w/Python 3.7:

https://koji.fedoraproject.org/koji/taskinfo?taskID=36637105

Yet this blocks the Python 3.8 rebuild.

For the build logs, see:
https://copr-be.cloud.fedoraproject.org/results/@python/python3.8/fedora-rawhide-x86_64/00989687-python-dateutil/

For all our attempts to build python-dateutil with Python 3.8, see:
https://copr.fedorainfracloud.org/coprs/g/python/python3.8/package/python-dateutil/

Testing and mass rebuild of packages is happening in copr. You can follow these instructions to test locally in mock if your package builds with Python 3.8:
https://copr.fedorainfracloud.org/coprs/g/python/python3.8/

Let us know here if you have any questions.
Comment 1 Petr Viktorin 2019-07-31 13:22:38 UTC 
BuildRequiring python3-pytest-cov should solve the symptoms, but I don't like the underlying issue: it seems that Pytest will now complain if tests contain coverage markers, but the coverage plugin is not available.
We generally don't want want to run coverage and linters in %check of distro packages. We might need a more systematic solution to this problem.
Comment 2 Miro Hrončok 2019-07-31 13:35:29 UTC 
https://docs.pytest.org/en/latest/changelog.html

pytest 4.5.0 added:

#5023: New flag --strict-markers that triggers an error when unknown markers (e.g. those not registered using the markers option in the configuration file) are used in the test suite.



I'm searching when this became the default (or if dateutil uses this or --scrict that implies it).
Comment 3 Miro Hrončok 2019-07-31 13:41:12 UTC 
https://docs.pytest.org/en/latest/mark.html "Unregistered marks applied with the @pytest.mark.name_of_the_mark decorator will always emit a warning..."

This is indeed a warning: _pytest.warning_types.PytestUnknownMarkWarning

Something is turning it into an error.
Comment 4 Miro Hrončok 2019-07-31 13:44:12 UTC 
Adding this to %prep workarounds the issue:

cat > pytest.ini << EOF
[pytest]
markers =
    no_cover
EOF
Comment 5 Miro Hrončok 2019-07-31 13:51:58 UTC 
pytest RFE https://github.com/pytest-dev/pytest/issues/5678
Comment 6 Miro Hrončok 2019-07-31 14:12:49 UTC 
This also workarounds the issue:

%{__python3} -m pytest -W ignore::pytest.PytestUnknownMarkWarning
Comment 7 Miro Hrončok 2019-08-12 23:29:54 UTC 
I've pushed the workaround:

%{__python3} -m pytest -W ignore::pytest.PytestUnknownMarkWarning