$ calibre Traceback (most recent call last): File "/usr/bin/calibre", line 20, in <module> sys.exit(calibre()) File "/usr/lib64/calibre/calibre/gui_launch.py", line 69, in calibre from calibre.gui2.main import main File "/usr/lib64/calibre/calibre/gui2/__init__.py", line 21, in <module> from calibre.utils.date import UNDEFINED_DATE File "/usr/lib64/calibre/calibre/utils/date.py", line 15, in <module> from calibre.utils.iso8601 import utc_tz, local_tz, UNDEFINED_DATE File "/usr/lib64/calibre/calibre/utils/iso8601.py", line 9, in <module> from dateutil.tz import tzlocal, tzutc, tzoffset File "/usr/lib64/python2.7/site-packages/dateutil/tz/__init__.py", line 1,<module> from .tz import * File "/usr/lib64/python2.7/site-packages/dateutil/tz/tz.py", line 23, in <le> from ._common import tzname_in_python2, _tzinfo, _total_seconds File "/usr/lib64/python2.7/site-packages/dateutil/tz/_common.py", line 2, module> from six.moves import _thread ImportError: cannot import name _thread Downgraded to 2.4.2-r1 and calibre opens
Thank you for your report, please add which versions are affected. Also fix the subject line accordingly, please.
calalibre 2.83.0 thru 2.85.1 pull in python-dateutil-2.6.0 which all fail to open as in the 1st comment
(In reply to Michael Rokicki from comment #0) > from calibre.utils.iso8601 import utc_tz, local_tz, UNDEFINED_DATE > File "/usr/lib64/calibre/calibre/utils/iso8601.py", line 9, in <module> > from dateutil.tz import tzlocal, tzutc, tzoffset > File "/usr/lib64/python2.7/site-packages/dateutil/tz/__init__.py", line > 1,<module> > from .tz import * > File "/usr/lib64/python2.7/site-packages/dateutil/tz/tz.py", line 23, in > <le> > from ._common import tzname_in_python2, _tzinfo, _total_seconds > File "/usr/lib64/python2.7/site-packages/dateutil/tz/_common.py", line 2, > module> > from six.moves import _thread > ImportError: cannot import name _thread This indicates a problem with the python-dateutil package. It could be a bug in the package or just an incorrect dependency.
The offending "from six.moves import _thread" code was removed in this commit (2.6.0-20-g9082c80): https://github.com/dateutil/dateutil/commit/9082c8047d899041059d7e68fa921a45e98d89c8 This change has not been tagged in a release. This test case succeeds for me with dev-python/six-1.10.0: python2.7 -c 'from six.moves import _thread' What version of dev-python/six do you have?
I have seen this behavior before when the user has installed an older version of six using pip. This conflicts with the newer six installed by portage. I suggest running the following commands to cleanup orphaned files from the python six package: rm -r /usr/lib64/python*/site-packages/six* emerge --oneshot dev-python/six
I'm very sorry for the long delay in posting this. The solution was to delete /usr/lib64/calibre/six.pyc which had no package associated. Figured out by chair-raver in https://forums.gentoo.org/viewtopic-t-1064862-highlight-.html
From the linked forum thread, this looks like a calibre problem. Didn't calibre had this very bad idea of requiring the setuid flag at some point? Maybe that this is what causes stray "six.pyc" files in /usr/lib. I'll let calibre maintainers decide what to do with this.
Like bug 622728, this may have been triggered by someone using upstream's "Binary install" method: https://calibre-ebook.com/download_linux
(In reply to Virgil Dupras (RETIRED) from comment #7) > Didn't calibre had this very bad idea of requiring the setuid flag at some > point? Maybe that this is what causes stray "six.pyc" files in /usr/lib. IIRC that was only ever a compiled helper program shipped with calibre... not python code. However, people might run calibre as root to get --help text, or run the content server as a daemon, or use the command-line conversion program... maybe they shouldn't, but maybe they did... ... Anyway, this has nothing to do with the binary install method which installs files to /opt that don't clash with a portage-managed copy of calibre. Somehow, back in 2017, the resulting image did not contain byte-compiled modules, and upgrading calibre left behind stale untracked files. In calibre 2.16 upstream, the vendored six.py file it distributed was deleted: https://github.com/kovidgoyal/calibre/commit/5454fca03ee1fdacdc98ffd71f5eb3b422256c53 Similarly, calibre 3.0 dropped its bundled regex module, cf. bug 622728 -- same issue there. That mismatch is particularly bad since it could leave behind cached .pyc but those then depend on the same directory containing the compiled *.so extensions. I have no idea whether compiled bytecode was properly handled in 2017, but it appears to be fine now and you should not be able to get untracked files. This issue is long gone.
