* This one is a false positive: python3-libs.x86_64: W: devel-file-in-non-devel-package /usr/include/python3.6m/pyconfig-64.h

Python uses the pyconfig.h file as a data file for runtime information so it has to be shipped with python-libs.

* I'm not sure about this one: python3-libs.x86_64: W: crypto-policy-non-compliance-openssl /usr/lib64/python3.6/lib-dynload/_ssl.cpython-36m-x86_64-linux-gnu.so SSL_CTX_set_cipher_list

but it may be needed to conform to upstream's API for SSL.  Python's stdlib is providing an SSL API for other software to use.  This may be a case where the API is able to make use of this for good or ill... but it is the application's choice, not Python's.).  You probably should get Christian Heimes' input on whether this is a problem or not as he deals with the security concerns in CPython quite heavily.

These are bogus (a C header apparently parsed as Bash):
python3.src:812: W: macro-in-comment %{_pyconfig32_h}
python3.src:814: W: macro-in-comment %{_pyconfig64_h}

(In reply to Toshio Ernie Kuratomi from comment #1)
> * This one is a false positive: python3-libs.x86_64: W:
> devel-file-in-non-devel-package /usr/include/python3.6m/pyconfig-64.h
> 
> Python uses the pyconfig.h file as a data file for runtime information so it
> has to be shipped with python-libs.
> 
> * I'm not sure about this one: python3-libs.x86_64: W:
> crypto-policy-non-compliance-openssl
> /usr/lib64/python3.6/lib-dynload/_ssl.cpython-36m-x86_64-linux-gnu.so
> SSL_CTX_set_cipher_list
> 
> but it may be needed to conform to upstream's API for SSL.  Python's stdlib
> is providing an SSL API for other software to use.  This may be a case where
> the API is able to make use of this for good or ill... but it is the
> application's choice, not Python's.).  You probably should get Christian
> Heimes' input on whether this is a problem or not as he deals with the
> security concerns in CPython quite heavily.

This warning is for compliance with the recent changes in crypto policies [0][1]

There is already ongoing work to address the issue upstream but it will land for 3.7 so we'll have to backport it when it's merged [2].

[0] https://fedoraproject.org/wiki/Packaging:CryptoPolicies
[1] bug 1489816
[2] https://github.com/python/cpython/pull/3532

> Actual spelling errors:
> python3-debug.x86_64: W: spelling-error %description -l en_US verisons -> versions, orisons, venison
> python3.src: W: spelling-error %description -l en_US readibility -> readability, credibility, reliability
> python3.x86_64: W: spelling-error %description -l en_US readibility -> readability, credibility, reliability

Fixed within PR: https://src.fedoraproject.org/rpms/python37/pull-request/6

> May be dangerous:
> python3-debug.x86_64: W: crypto-policy-non-compliance-openssl /usr/lib64/python3.6/lib-dynload/_ssl.cpython-36dm-x86_64-linux-gnu.so SSL_CTX_set_cipher_list
> python3-libs.x86_64: W: crypto-policy-non-compliance-openssl /usr/lib64/python3.6/lib-dynload/_ssl.cpython-36m-x86_64-linux-gnu.so SSL_CTX_set_cipher_list

Fixed upstream in https://github.com/python/cpython/pull/3532 (as per Comment 3).
The warning though will still be present as per ticket description in https://bugs.python.org/issue31429: in case --with-ssl-default-suites option is not passed, Python shall set a default suite. In our Python 3 builds the option is now enabled, so the warning is not relevant.

> python3-debug.x86_64: E: library-without-ldconfig-postin /usr/lib64/libpython3.6dm.so.1.0
> python3-debug.x86_64: E: library-without-ldconfig-postun /usr/lib64/libpython3.6dm.so.1.0

Already fixed https://src.fedoraproject.org/rpms/python3/c/14deb52d02decabd7dda8bcfa01e628031f03414
Scriplets removed, this should be done automatically.

> Probably bogus but worth looking:
> python3.x86_64: W: self-obsoletion python36 obsoletes python36 = 3.6.4-3.fc28
> python3.src:398: W: unversioned-explicit-obsoletes python%{pyshortver}

The comment in the spec file explains why: 
"""
# Note that using Obsoletes without package version is not standard practice.
# Here we assert that *any* version of the system's default interpreter is
# preferable to an "extra" interpreter
"""

> No idea:
> python3-debug.x86_64: E: missing-call-to-chdir-with-chroot /usr/lib64/libpython3.6dm.so.1.0
> python3-libs.x86_64: E: missing-call-to-chdir-with-chroot /usr/lib64/libpython3.6m.so.1.0

This is the implementation of os.chroot

> python3-debug.x86_64: W: read-error /usr/lib64/pkgconfig/python-3.6dm.pc [Errno 2] No such file or directory: '/tmp/rpmlint.python3-debug-3.6.4-3.fc28.x86_64.rpm.jk21bauv/usr/lib64/pkgconfig/python-3.6dm.pc'

python-3.6dm.pc is a link to python-3.6.pc which is in the python3-devel subpackage, which python3-debug requires.

> python3-libs.x86_64: W: devel-file-in-non-devel-package /usr/include/python3.6m/pyconfig-64.h

False positive as per Comment 1

> Not that important, but right:
> python3.src:812: W: macro-in-comment %{_pyconfig32_h}
> python3.src:814: W: macro-in-comment %{_pyconfig64_h}

False positive as per Comment 2

> python3.src:1731: W: macro-in-%changelog %py_byte_compile

Already fixed https://src.fedoraproject.org/rpms/python3/c/40b8f9ece20b5f9cbaf3d2fd78a39a3158dfa0c5

> python3.src:130: W: mixed-use-of-spaces-and-tabs (spaces: line 15, tab: line 130)

Fixed within PR: https://src.fedoraproject.org/rpms/python37/pull-request/6

This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle.
Changing version to '28'.

Backported to python3 in Rawhide: https://src.fedoraproject.org/rpms/python3/pull-request/24

Closing as Rawhide, please reopen if necessary.