Opening a file in binary mode in python3 returns a BufferedReader which
does not have an encoding attribute. Assume in this case it is
functionally equivalent to None.
I'm not sure when pml_stream.encoding will ever equal anything, since
even on python2 the attribute exists but is None when opening files in
binary mode... which we explicitly do. So I'm not sure why this ever
checks the existing encoding. Possibly when the input plugin is given a
file opened in text mode, not raw mode? in that case, it may be wrong to
always decode it when reading.
in python3, the re module is more picky about what arguments are used
with it, and invalid escapes do not fall back on being treated as string
literals, but raise an error. Use raw strings to ensure that the escaped
backslashes are preserved all the way to the regular expressions
themselves.
get_id_tag/get_id_tag_by_pos_fid are internal functions that always
return bytes, but when using the former proxied through the latter, we
did not always decode the result in the process of generating an OPF.
As a result, books would end up with nav links pointing to urls
resembling "foo.html#b'anchor'".
Fix by moving down the decode attempt to cover both, right before
writing it back into the index_entries.
Not needed with html5-parser 0.4.6
Modify the test to work with all versions of html5-parser
Fixes#990 (Update testsuite for html5-parser 0.4.6 changes)
Since xdg-mime only cares about basename(filename) and that filename is
an existing file (and we don't know where the installed one is), create
an empty file with the right name and then delete that.
The uninstaller is only meant to be used on systems where calibre is
being installed live. For staged installs, it can be assumed that the
same mechanism which takes care of installing files from the staging dir
to live systems, is also able to remove calibre when desired. Usually
this will be a linux package manager.
Injecting the location of the mime_resources file from P() in non-frozen
builds will depend on the mime resource from the source tree rather than
the same location during install time... a source tree which may be
deleted after successful installation. On a frozen build, or when using
'develop' instead of 'install', this path will be the same, and things
just work.
The solution is to add *both* paths, and try to uninstall whichever one
exists.
In order for xdg-utils programs to successfully install resources to the
staging root instead of /usr, this variable needs to be set and
additionally some arcane directories must be created that xdg-utils,
astoundingly, does not know how to just gracefully handle.
xdg-mime is simply hopeless as it does not have a --noupdate flag. When
using a staged install, copy it with shutil instead.
This creates an additional variable containing the version number
extracted from a git checkout via `git describe`, and diverts all
human-readable output to use that via get_version.
The Windows-specific hack initially added in commit
8743efbed1 should be able to be removed
now as it is no longer necessary. The python encoding on Windows is sane
in python3.
Eli Schwartz
Kovid Goyal
j-howell
Aimylios
Charles Haley
David