Description of problem: The mtime of all pyc files is 1970-01-01T00:00:00.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. rpmlint ./python37-3.7.0-0.12.b2.fc29.x86_64.rpm | grep python-bytecode-inconsistent-mtime
python37.x86_64: E: python-bytecode-inconsistent-mtime /usr/lib64/python3.7/__pycache__/__future__.cpython-37.opt-1.pyc 1970-01-01T01:00:00 /usr/lib64/python3.7/__future__.py 2018-02-28T01:49:18
python37.x86_64: E: python-bytecode-inconsistent-mtime /usr/lib64/python3.7/__pycache__/__future__.cpython-37.opt-2.pyc 1970-01-01T01:00:00 /usr/lib64/python3.7/__future__.py 2018-02-28T01:49:18
python37.x86_64: E: python-bytecode-inconsistent-mtime /usr/lib64/python3.7/__pycache__/__future__.cpython-37.pyc 1970-01-01T01:00:00 /usr/lib64/python3.7/__future__.py 2018-02-28T01:49:18
python37.x86_64: E: python-bytecode-inconsistent-mtime /usr/lib64/python3.7/__pycache__/__phello__.foo.cpython-37.opt-1.pyc 1970-01-01T01:00:00 /usr/lib64/python3.7/__phello__.foo.py 2018-02-28T01:49:18
See also Bug 1373635, yet this is different (all the mtimes are 1970-01-01T01:00:00 here).
This might or might not be related to https://docs.python.org/dev/whatsnew/3.7.html#hash-based-pycs
$ LANG=C.utf-8 rpm -qlvp .../python37-3.7.0-0.12.b2.fc29.x86_64.rpm (shortened)
Feb 28 01:49 /usr/lib64/python3.7/__future__.py
Feb 28 14:27 /usr/lib64/python3.7/__pycache__/__future__.cpython-37.opt-1.pyc
Feb 28 14:27 /usr/lib64/python3.7/__pycache__/__future__.cpython-37.opt-2.pyc
Feb 28 14:27 /usr/lib64/python3.7/__pycache__/__future__.cpython-37.pyc
i.e. not 1970-01-01T01:00:00
So this is not the mtime of the pyc file, but rpmlint reads the mtime from withing the pyc file.
From PEP 552:
The pyc header currently consists of 3 32-bit words. We will expand it to 4. The first word will continue to be the magic number, versioning the bytecode and pyc format. The second word, conceptually the new word, will be a bit field. The interpretation of the rest of the header and invalidation behavior of the pyc depends on the contents of the bit field.
So apparently rpmlint reads this second word by:
pyc_timestamp = py_demarshal_long(chunk[4:8])
And gets zero.
Should I keep this open for Fedora 28 and 27?
Well, seeing as how I still can't actually build rpmlint in rawhide, I think it would be premature to call this closed.
Oh. I failed to notice that it fails. let me guess, flake8?
I'll send you a PR.
Okay, thanks. Do we actually need this fix pushed back for F27/F28?
The python37 package will scream, but I can live with that.
It's not really necesery. Thanks.