Description of problem:
Rpm's python3 API has been totally braindamaged all this time but people are only noticing now that it's starting to get used.
We're changing rpm to return all string data as surrogate-escaped utf-8 python strings everywhere (instead of bytes with unknown encoding that the API doesn't otherwise even accept, see bug 1631292). This makes most rpm-scripts written for python2 just work with python3 too (from the rpm pov).
Most software that has kept python2 compatibility are automatically compatible with the fixed API, but unfortunately python3-only users like rpmlint need fixing for the new behavior.
There's at least one affected place in rpmlint, which will after the change start failing with the following traceback:
Traceback (most recent call last):
File "/usr/bin/rpmlint", line 378, in <module>
File "/usr/bin/rpmlint", line 166, in main
File "/usr/bin/rpmlint", line 223, in runChecks
File "/usr/share/rpmlint/TagsCheck.py", line 695, in check
self.check_summary(pkg, lang, ignored_words)
File "/usr/share/rpmlint/TagsCheck.py", line 903, in check_summary
if not Pkg.is_utf8_bytestr(summary):
File "/usr/share/rpmlint/Pkg.py", line 168, in is_utf8_bytestr
AttributeError: 'str' object has no attribute 'decode'
As the broken rpm versions are widely in use, it's best to keep compatibility with both initially. One possible way to fix this is simply:
--- Pkg.py.orig 2019-03-28 16:06:54.491218904 +0200
+++ Pkg.py 2019-03-28 16:07:13.412186582 +0200
@@ -168,6 +168,8 @@
+ except AttributeError:
+ return True
I was pointed out that the bug referred to in the message is a private RHEL bug, sorry about that.
The public, Fedora side counterpart with the background story is the one blocked by this, ie
*** Bug 1699789 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of bug 1722868 ***